Análise de fluxo de dados com exceções

A análise de fluxo de dados funciona sobre um gráfico de fluxo de controle. Quando um idioma em consideração suporta exceções, o gráfico de fluxo de controle pode explodir.

Quais são as técnicas padrão para lidar com essa explosão? Podemos ignorar profundamente as arestas induzidas pela exceção? As análises de fluxo de dados, de qualquer forma, calculam super aproximações, para que acabemos com uma solução menos precisa, mas sólida. Isso é verdade?

Atualização : Aqui estão alguns links úteis que consegui desenterrar no final:

programming-languages program-optimization software-verification

— bellpeace
fonte

O que você quer dizer com "explodir"? Estaticamente, sabemos quais exceções podem ser lançadas onde? Que tipo de aumento de tamanho você gostaria de aceitar?

— Raphael

Por explosão, quero dizer que o número de blocos básicos é aumentado e o número de arestas que os conectam, resultando em tempos de execução de análise potencialmente mais altos. Minha suposição, talvez errada, foi que isso pode ser um problema nos compiladores e talvez haja alguma maneira de lidar com isso. Estou interessado em entender o assunto.

— bellpeace

Ignorar exceções não é válido. Exemplo:

let g = {
     raise E;
}
let f = {
     x := interesting_stuff();
     g();
     x := 0;
}

Ao analisar f, é necessário levar em consideração o fato que ggera uma exceção; caso contrário, você concluiria incorretamente que xsempre é 0 no retorno de f.

Não sei se existe uma técnica "padrão" para lidar com exceções. Há alguma literatura sobre o assunto, não tenho mais idéia de quais artigos são relevantes do que posso encontrar em uma pesquisa no Google.

Formalmente, as exceções podem ser transformadas em instruções condicionais que propagam a cadeia de chamadas, o que naturalmente explode o gráfico de fluxo de controle. Em muitos casos concretos, o caso de exceção é o menos interessante, onde muitos dados são mortos, portanto, devem ser tratados preguiçosamente em uma abordagem avançada (não é necessário analisar a animação no caminho da exceção, se o manipulador matar os dados) .

— Gilles 'SO- parar de ser mau'
fonte

Uma pergunta de acompanhamento, se você não se importa. Essencialmente, se estiver faltando algumas arestas, posso obter um resultado incorreto. E se eu tiver bordas codificando o fluxo de controle que de fato não é exibido durante a execução do programa? Eu teria um resultado sólido, mas potencialmente menos preciso?

— bellpeace

@bellpeace Se uma borda corresponde a um caminho que nunca é percorrido durante a execução, é um código morto, para que possa ser removida sem afetar a integridade. O resultado seria mais preciso: você tem uma melhor aproximação do programa, para obter uma melhor aproximação do seu comportamento.

— Gilles 'SO- stop be evil'

Então, essencialmente, adicionar arestas adicionais não afetará a sonoridade, mas apenas a precisão?

— bellpeace

@bellpeace Sim: se você adicionar caminhos em potencial, poderá introduzir novos fluxos em potencial que realmente não podem acontecer, mas não apagará nenhum fluxo que acontecer.

— Gilles 'SO- stop be evil'

Espere, neste exemplo, x é sempre zero no retorno de f. Se g gera uma exceção, f não retorna. Agora, se f capturasse a exceção (e talvez reconstituísse), isso seria uma questão diferente, mas seria uma margem explícita no gráfico de fluxo.

— Pseudônimo