[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