>
> I am not so sure about this when it come to relatively common
> instructions. Hiding things in unspec prevents combine and other RTL
> passes from doing their job. I would say that it only makes sense for
> siutations where RTL equivalent is very inconvenient.
>
In the direction of using gener
> > And thus it may be more RTL friendly to represent it this way instead of
> > current unspec called UNSPEC_IEEE_MAX...
>
> There's a patch proposed for that [1], and Jakub has some comments.
>
> Jakub Jelinek 于2024年11月15日周五 16:20写道：
> >
> > On Fri, Nov 15, 2024 at 04:04:55PM +0800, Hongyu Wan
> Note for blendv, it checks the significant bit of the mask, not simple
> if_then_else
> mask
> if_true
> if_false
>
> It should be
> if_then_else
>ashiftrt mask 31
>if_true
>if_false
I think canonical form (produced by combine) would be
if_then_else
ge mask 0
if_false
On Fri, Apr 25, 2025 at 1:26 PM Jan Hubicka wrote:
>
> > On Thu, Apr 24, 2025 at 6:27 PM Jan Hubicka wrote:
> > >
> > > > Since ix86_expand_sse_movcc will simplify them into a simple vmov, vpand
> > > > or vpandn.
> > > > Current register_operand/vector_operand could lose some optimization
> > >
> On Thu, Apr 24, 2025 at 6:27 PM Jan Hubicka wrote:
> >
> > > Since ix86_expand_sse_movcc will simplify them into a simple vmov, vpand
> > > or vpandn.
> > > Current register_operand/vector_operand could lose some optimization
> > > opportunity.
> > >
> > > Bootstrapped and regtested on x86_64-pc
> -Original Message-
> From: Jan Hubicka
> Sent: Friday, April 25, 2025 12:27 AM
> To: Liu, Hongtao
> Cc: gcc-patches@gcc.gnu.org; crazy...@gmail.com; hjl.to...@gmail.com
> Subject: Re: [PATCH] Accept allones or 0 operand for vcond_mask op1.
>
> > Since
On Thu, Apr 24, 2025 at 8:10 PM Uros Bizjak wrote:
>
> On Thu, Apr 24, 2025 at 6:27 PM Jan Hubicka wrote:
> >
> > > Since ix86_expand_sse_movcc will simplify them into a simple vmov, vpand
> > > or vpandn.
> > > Current register_operand/vector_operand could lose some optimization
> > > opportunit
On Thu, Apr 24, 2025 at 6:27 PM Jan Hubicka wrote:
>
> > Since ix86_expand_sse_movcc will simplify them into a simple vmov, vpand
> > or vpandn.
> > Current register_operand/vector_operand could lose some optimization
> > opportunity.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,
> Since ix86_expand_sse_movcc will simplify them into a simple vmov, vpand
> or vpandn.
> Current register_operand/vector_operand could lose some optimization
> opportunity.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> * config/i386/p
On Mon, Apr 21, 2025 at 2:52 PM liuhongt wrote:
>
> Since ix86_expand_sse_movcc will simplify them into a simple vmov, vpand
> or vpandn.
> Current register_operand/vector_operand could lose some optimization
> opportunity.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for tru
Since ix86_expand_sse_movcc will simplify them into a simple vmov, vpand
or vpandn.
Current register_operand/vector_operand could lose some optimization
opportunity.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
* config/i386/predicates.md (vector
11 matches
Mail list logo
