I moderni compilatori di oggi eseguono controlli di runtime?

1

Questo riguarda i compilatori.

I compilatori eseguono verifiche di dipendenza in fase di esecuzione per decidere di vettorizzare un ciclo? In altre parole, i compilatori tracciano la logica come se fosse in fase di esecuzione per determinare se un loop può essere vettorizzato?

È così che quando il compilatore compila un codice e se l'auto-vettorizzazione è abilitata (default) allora l'output è un codice vettorizzato mirato con diciamo le istruzioni di assemblaggio AVX e quando ha eseguito i controlli di dipendenza?

    
posta satej k 26.02.2015 - 12:53
fonte

2 risposte

5

Per fare in modo che un compilatore esegua i controlli del tempo di esecuzione (per trovare avvertenze ed errori che non possono essere trovati in fase di compilazione, inclusa la vettorizzazione del ciclo), inizia ad avvicinarsi pericolosamente al Halting Problem.

Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist. A key part of the proof was a mathematical definition of a computer and program, which became known as a Turing machine; the halting problem is undecidable over Turing machines. It is one of the first examples of a decision problem.

Considera il seguente programma Java:

public class Halting {
  public static void main(String... args) {
    while(isCondition()) {

    }
  }

  private static boolean isCondition() {
    return true;
  }
}

Questo programma non restituisce errori o avvisi dal compilatore. Dovrebbe tracciare attraverso la logica per vedere che è un ciclo infinito. Cosa significa fermare il correttore teorico del tempo di esecuzione per non rimanere bloccato in un loop infinito allo stesso modo? Il compilatore non può rimanere bloccato in un ciclo infinito, non è abbastanza intelligente .

Notate, d'altra parte, che questo ha un errore:

public class Halting {
  public static void main(String... args) {
    String foo = null;
    System.out.println(foo.charAt(0));
  }
}

Questo produce l'avviso:

Null pointer access: The variable foo can only be null at this location

Questi controlli sono i migliori che il compilatore possa fare. Ma nota che questo non ha alcun avvertimento, anche se è lo stesso problema:

public class Halting {
  public static void main(String... args) {
    String foo = getFoo();
    System.out.println(foo.charAt(0));
  }

  private static String getFoo() {
    return null;
  }
}
    
risposta data 26.02.2015 - 19:12
fonte
0

Non penso che nessuno lo faccia, ma dovrebbe essere possibile. Ad esempio gcc 4.8 (scorri verso il basso fino alla sezione IA-32 / x86-64) ha sia un __builtin_cpu_support integrato funzione e funzione supporto multiversioning che lo sviluppatore può utilizzare per scrivere codice diverso per diverse architetture. Non vedo perché il compilatore non sia in grado di generare diversi codepath dipendenti dal runtime utilizzando queste funzionalità automaticamente.

Ad esempio, manualmente:

__attribute__ ((target ("default")))
int foo(void)
{
  return 1;
}

__attribute__ ((target ("sse4.2")))
int foo(void)
{
  return 2;
}

int main (void)
{
  int (*p) = &foo;
  assert ((*p)() == foo());
  return 0;
}
    
risposta data 26.02.2015 - 19:46
fonte

Leggi altre domande sui tag