[Patch] x86: Enable support for Intel UINTR extension

[Hongtao Liu]

On Wed, Oct 14, 2020 at 5:21 PM Uros Bizjak <ubizjak@gmail.com> wrote:
>
> 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?
>

Because of function target attribute?

> Uros.



-- 
BR,
Hongtao