[Patch] x86: Enable support for Intel UINTR extension

Uros Bizjak ubizjak@gmail.com
Wed Oct 14 09:21:37 GMT 2020


On Wed, Oct 14, 2020 at 11:04 AM Hongyu Wang <wwwhhhyyy333@gmail.com> wrote:
>
>
>
> Uros Bizjak <ubizjak@gmail.com> 于2020年10月14日周三 下午4:42写道:
>>
>> On Wed, Oct 14, 2020 at 10:34 AM Hongyu Wang <wwwhhhyyy333@gmail.com> wrote:
>> >
>> > >
>> > > Please also add -muintr to g++.dg/other/i386-{2,3}.C and
>> > > gcc.target/i386-sse-{12,13,14,22,23}.c. This will test new intrinsics
>> > > header.
>> > >
>> >
>> > Thanks for your review. We found that without adding -muintr, the intrinsics header could also be tested. Make-check for these file all get passed.
>> >
>> > And there is no intrinsic/builtin with const int parameter. So we remove -muintr from these files.
>>
>> Can your double check that relevant instructions are indeed generated?
>> Without -muintr, relevant patterns in i386.md are effectively blocked,
>> and perhaps a call to __builtin_ia32_* is generated instead.
>
>
> Yes, in sse-14.s we have
>
> _clui:
> .LFB136:
>         .cfi_startproc
>         pushq   %rbp
>         .cfi_def_cfa_offset 16
>         .cfi_offset 6, -16
>         movq    %rsp, %rbp
>         .cfi_def_cfa_register 6
>         clui
>         nop
>         popq    %rbp
>         .cfi_def_cfa 7, 8
>         ret
>         .cfi_endproc

Strange, without -muintr, it should not be generated, and some error
about failed inlining due to target specific option mismatch shoul be
emitted.

Can you please investigate this a bit more?

Uros.


More information about the Gcc-patches mailing list