Design: Предложение: флаги уровня соответствия Fp IEEE для Wasm (FP-Fast-Math для Wasm Scalar и SIMD)

Поскольку строгость операций fp влияет на семантику программы, я ожидаю, что лучший способ сделать возможной более разрешающую семантику — это ввести новые инструкции, а не пользовательский раздел или конструкцию блока. У нас уже есть механизмы спецификации, необходимые для обработки недетерминизма с плавающей запятой из-за наших правил распространения NaN, поэтому я ожидаю, что будет просто ввести новые инструкции с плавающей запятой, которые позволяют получить больше возможных результатов.

В качестве дополнительного контекста JVM, со своей стороны, рассматривает возможность удаления strictfp и поддержки только строгой семантики.

лучший способ сделать возможной более разрешающую семантику — это ввести новые инструкции, а не пользовательский раздел или блочную конструкцию.

Введение новых инструкций полезно, но оно не будет слишком хорошо масштабироваться или полностью устранять зависимость от цепочки инструментов. Инструкции с хорошей поддержкой платформы, такие как fma, reciprocal и т. д., являются хорошими кандидатами на добавление новых инструкций. Подсказки/флаги, предлагаемые нативными компиляторами, весьма
-fassociative-math -ffast-math -fno-honor-nans -ffinate-math-only -fdenormal-fp-math -fno-strict-float-cast-overflow -fno-math-errno -fno-trapping-math ...
Большинство из них являются подсказками, позволяющими более агрессивно оптимизировать fp, снимая ограничения на алгебраические преобразования, nans, нули со знаком, ловушки, округление и т. д. Выражение всех полезных флагов в виде новых инструкций не является идеальным imo.

В качестве дополнительного контекста JVM, со своей стороны, рассматривает возможность удаления strictfp и поддержки только строгой семантики.

Спасибо @sunfishcode за добавленный контекст! Я не знал об этом новом обновлении и, похоже, мотивация состоит в том, чтобы объединить варианты математических библиотек. При ближайшем рассмотрении Java strict-fp кажется немного более специализированным и не является хорошим представлением диапазона контрольных точек, предлагаемых gcc/clang. Флаги -ffast-math и связанные с ними флаги кажутся довольно популярными в нативных репозиториях из быстрого поиска на github. Я планирую изучить использование вышеуказанных флагов и связанных с ними паргм.

Типичные проекты, использующие gcc/clang -ffast-math, компилируются в собственный код. Разработчики приложений, использующие их, обычно тестируют все варианты нативного кода, которые они сами создают. А поскольку все популярные аппаратные ISA имеют полностью детерминированное поведение с плавающей запятой, после того, как разработчики протестировали эти варианты, они могут быть уверены, что поведение не изменится для их пользователей. В настоящее время так же работает WebAssembly с плавающей запятой; он полностью детерминирован, как и аппаратные ISA, поэтому существующие давние предположения разработчиков о возможности добавления -ffast-math и проверки того, что он «работает для них», поддерживаются.

Флаг -ffast-math уровня WebAssembly будет означать, что WebAssembly больше не похож на аппаратную ISA в этом отношении и больше не поддерживает эти предположения. Разработчики будут тестировать созданный ими двоичный файл, но при отправке wasm своим пользователям их пользователи должны ожидать, что смогут запускать его на другом оборудовании или других движках. С флагами, подобными быстрой математике, на уровне WebAssembly, WebAssembly не будет вести себя как ISA, и пользователи смогут увидеть результаты вычислений с плавающей запятой, отличные от тех, с которыми тестировал разработчик.

Также стоит отметить, что проекты, использующие эти флаги, сегодня не теряются при компиляции в WebAssembly. Например, многие оптимизации, доступные с помощью -fassociative-math, являются оптимизациями, ориентированными на циклы, которые LLVM может выполнять до создания WebAssembly.

Да, любые решения, влияющие на точность/поведение float, должны быть встроены в модуль Wasm с помощью инструментов. Новые инструкции могут быть добавлены для поведения, которое не может быть выражено текущими.

У нас была дискуссия на эту тему на последнем собрании CG с добавлением новой инструкции как альтернативного средства достижения цели. По-видимому, существует общий интерес к решению этого вопроса в последнем направлении. У меня нет возражений, если ожидания разработчиков в отношении прироста производительности могут быть подтверждены оптимизацией цепочки инструментов и введением отсутствующих вариантов инструкций. В этом случае нет никакой необходимости оправдывать распространение этих флагов во время выполнения, ставя под угрозу уровень абстракции Wasm. Будет полезно понять инструкции семантического варианта, которые необходимы для достижения этой цели. У нас есть несколько новых инструкций, идентифицированных в контексте SIMD, которые, возможно, потребуется расширить, чтобы они соответствовали инструкциям, которые необходимы инструментам для полного выражения флагов быстрой математики. Буду продолжать искать в этом направлении.

Спасибо за ответ.

Контент, используемый для обсуждения компьютерной графики. Wasm ffast-math.pptx