Desde o anúncio das Advanced Performance Extensions (APX) e do AVX10 em julho, os engenheiros de compiladores de código aberto da Intel têm estado ocupados preparando as cadeias de ferramentas do compilador GCC e LLVM/Clang para essas principais extensões de CPU que serão encontradas nos futuros processadores Intel.
Houve o suporte inicial para o AVX10.1 adicionado ao GNU Compiler Collection (GCC), preparações do GNU Assembler e muito mais. Nos últimos dias, os engenheiros de compiladores da Intel também publicaram mais patches.
Na quinta-feira passada, foram enviados o -mevex512 para patches AVX-512 e relacionados -mno-evex512 para alternar o registro de 512 bits e o registro de máscara de 64 bits.
Após a discussão anterior, em vez de oferecer suporte à opção -mavx10.1, primeiro [introduziremos] a opção -m[no-]evex512, que ativará/desativará o registro de 512 bits e o registro de máscara de 64 bits.
Isso não alterará o comportamento da opção atual, pois se AVX512F estiver ativado sem nenhuma opção evex512 especificada, ele ativará automaticamente o registro de 512 bits e o registro de máscara de 64 bits.
O andamento dos patches é o seguinte:
O patch 1 adicionou suporte inicial para a opção -mevex512.
O patch 2-6 refinou o arquivo intrínseco atual para enviar o alvo evex512 para todos os intrínsecos de 512 bits. Essas intrínsecas escalares permaneceram intocadas.
Patch 7-11 adicionou OPTION_MASK_ISA2_EVEX512 para todos os componentes internos relacionados.
O patch 12 desativou o registro zmm, chamada libmvec de 512 bits para no-evex512, também solicitou evex512 para vetorização ao usar o registro de 512 bits.
O patch 13-17 oferece suporte a evex512 em padrões relacionados.
O Patch 18 adicionou casos de teste para o -mno-evex512 e permitiu seu uso.
Os patches atualmente causam falha no scan-asm para pr89229-{5,6,7}bc, pois emitiremos vmovss escalares aqui. Ao tentar usar x/ymm 16+ sem avx512vl, mas com avx512f+evex512, suponho que poderíamos emitir instruções escalares ou zmm. É um caso bastante raro em HW, já que não há HW sem avx512vl, mas com avx512f, então prefiro não adicionar esforço [de manutenção] aqui para obter uma ligeira melhoria de desempenho. Mas poderia ser mudado para o comportamento anterior.
Os Patches atualizados separadamente na preparação do suporte APX EGPR foram publicados na sexta-feira. Conforme explicado nos patches APX EGPR anteriores para GCC:
"A extensão de desempenho Intel Advanced (APX) foi lançada. Ela contém várias extensões, como 16 registros de uso geral estendidos (EGPRs)...APX introduz um prefixo REX2 para ajudar a representar EGPR para várias instruções legadas/SSE. Para os restantes, ele promove alguns deles usando o prefixo evex para EGPR. O principal problema no APX é que nem todas as instruções legadas/sse/vex suportam EGPR. Por exemplo, instruções no código de operação legado map2/3 não podem usar o prefixo REX2, pois há apenas 1 bit no REX2 para indicar instruções map0/1, por exemplo, pinsrd. Além disso, para a maioria das extensões de vetor, EGPR é suportado em suas formas evex, mas não em formas vex, o que significa que os mnemônicos sem formas evex também não podem usar EGPR, por exemplo, vphaddw. Essa limitação traz algum desafio com a infraestrutura atual do GCC...."
Portanto, com os patches APX EGPR para o GCC, há manipulação de instruções legadas, código de habilitação APX_F inicial e outros trabalhos iniciais de preparação para as extensões de desempenho avançado da Intel.
Os esforços APX e AVX10.2+ são um grande empreendimento, mas pelo menos os engenheiros de código aberto/Linux da Intel têm sido muito ativos no lançamento rápido de novos patches e na obtenção de upstream de bits relevantes, de modo que, quando os processadores aparecerem com esses recursos, deverão seja um bom suporte para Linux pronto para o uso.
Até a próxima !!
Nenhum comentário:
Postar um comentário