Design: Proposta: Sinalizadores de nível de conformidade Fp IEEE para Wasm (FP-Fast-Math para Wasm Scalar e SIMD)

Como o rigor das operações fp afeta a semântica de um programa, eu esperaria que a melhor maneira de tornar possível uma semântica mais permissiva fosse introduzir novas instruções em vez de uma seção personalizada ou construção de bloco. Já temos os mecanismos de especificação necessários para lidar com o não determinismo flutuante devido às nossas regras de propagação de NaN, então espero que seja simples introduzir novas instruções de ponto flutuante que permitam mais resultados possíveis.

Como contexto adicional, a JVM, por sua vez, está considerando remover strictfp e suportar apenas a semântica estrita.

a melhor maneira de tornar possível uma semântica mais permissiva seria introduzir novas instruções em vez de uma seção personalizada ou construção de bloco.

A introdução de novas instruções é útil, mas não será dimensionada muito bem ou removerá completamente a dependência da cadeia de ferramentas. As instruções com bom suporte de plataforma como fma, recíproca etc são boas candidatas para a adição de novas instruções. Existe uma variedade considerável de
-fassociative-math -ffast-math -fno-honor-nans -ffinate-math-only -fdenormal-fp-math -fno-strict-float-cast-overflow -fno-math-errno -fno-trapping-math ...
A maioria dessas são dicas para permitir otimizações de fp mais agressivas, levantando restrições em transformações algébricas, nans, zeros assinados, armadilhas, arredondamentos etc. Expressar todos os sinalizadores úteis como novas instruções não é o ideal imo.

Como contexto adicional, a JVM, por sua vez, está considerando remover o strictfp e suportar apenas a semântica estrita.

Obrigado @sunfishcode por este contexto adicionado! Eu não sabia dessa nova atualização e parece que a motivação é consolidar as variantes da biblioteca de matemática. Olhando mais de perto, o Java strict-fp parece ser um pouco mais especializado e não é uma boa representação do intervalo de pontos de controle oferecidos pelo gcc/clang. -ffast-math sinalizadores e sinalizadores associados parecem ser bastante populares em repositórios nativos a partir de uma pesquisa rápida no github. Eu pretendo analisar os usos dos sinalizadores acima e os pargmas associados

Projetos típicos que usam o -ffast-math do gcc/clang estão compilando para código nativo. Os desenvolvedores de aplicativos que os utilizam normalmente testam todas as variantes de código nativo que eles mesmos criam. E como todos os ISAs de hardware populares têm comportamento de ponto flutuante totalmente determinístico, uma vez que os desenvolvedores testaram essas variantes, eles podem ter certeza de que o comportamento não mudará para seus usuários. Atualmente, o ponto flutuante do WebAssembly também funciona dessa maneira; é totalmente determinístico, assim como os ISAs de hardware, portanto, as suposições de longa data dos desenvolvedores sobre a capacidade de adicionar -ffast-math e testar se "funciona para eles" são mantidas.

Um sinalizador -ffast-math no nível do WebAssembly significaria que o WebAssembly não se assemelha mais a um ISA de hardware a esse respeito e não mantém mais essas suposições. Os desenvolvedores testariam o binário que produzem, mas ao enviar o wasm para seus usuários, eles devem esperar poder executá-lo em diferentes hardwares ou mecanismos diferentes. Com sinalizadores de matemática rápida no nível do WebAssembly, o WebAssembly não se comportaria como um ISA, e os usuários poderiam ver resultados de ponto flutuante diferentes dos que o desenvolvedor testou.

Também vale a pena ressaltar que os projetos que usam esses sinalizadores não estão perdendo ao compilar para o WebAssembly hoje. Por exemplo, muitas das otimizações habilitadas por -fassociative-math são otimizações orientadas a loops que o LLVM pode fazer antes de produzir o WebAssembly.

Sim, quaisquer decisões que afetem a precisão/comportamento da flutuação devem ser inseridas no módulo Wasm pelas ferramentas. Novas instruções podem ser adicionadas para comportamentos que não podem ser expressos com as atuais.

Tivemos uma discussão sobre esse tema na última reunião do CG com a adição da nova instrução como meio alternativo para o objetivo. Parece haver um interesse geral em resolver isso através da última direção. Não tenho objeções se as expectativas do desenvolvedor sobre ganhos de desempenho puderem ser mantidas por otimizações da cadeia de ferramentas e pela introdução de variantes de instrução ausentes. Nesse caso, não há necessidade de justificar a propagação desses sinalizadores para o runtime comprometendo o nível de abstração do Wasm. Será bom entender as instruções da variante semântica que são necessárias para atingir esse objetivo. Temos algumas novas instruções identificadas no contexto do SIMD que podem precisar ser estendidas para corresponder às necessidades das ferramentas de instruções para expressar totalmente os sinalizadores de matemática rápida. Continuará olhando nessa direção.

Obrigado pelo feedback.

Conteúdo usado para discussão de CG. Wasm ffast-math.pptx