This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: x86 SSE constants
- From: Jan Hubicka <jh at suse dot cz>
- To: Richard Henderson <rth at redhat dot com>,Dale Johannesen <dalej at apple dot com>, Jan Hubicka <hubicka at ucw dot cz>,gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Sat, 1 Oct 2005 17:42:13 +0200
- Subject: Re: x86 SSE constants
- References: <911f975f2625580327e1db45f490eb32@apple.com> <20050930231738.GE7482@atrey.karlin.mff.cuni.cz> <2fd4421d58b80d5237ac3e5a48523d4f@apple.com> <20051001002451.GC21135@redhat.com>
> On Fri, Sep 30, 2005 at 04:31:59PM -0700, Dale Johannesen wrote:
> > No, there isn't, but it might be a smaller change to add a new
> > constraint....
> > having constraints tied to specific constants is pretty ugly, and so is
> > having (if (constant value==0)) in a lot of patterns..,,
>
> That's why you'd centralize this into a few functions. There
> are several things that need changing:
>
> * Match different forms of constant for C.
>
> * Update vector_move_operand to use that same routine.
>
> * A routine to determine which of several instructions
> we want to emit. E.g. xorps instead of pxor for -Os.
> It should return a ATTR_MODE result so that we can
> call it from the mode attribute of various instructions.
>
> * A routine that uses the previous to return a const char*
> template to return from the insn output patterns.
>
> For bonus points, handle MMX too.
Yep. It seems to me that current way
standard_80387_constant_p/standard_80387_constant_opcode and 'G'
constraint is handled is pretty much symetrical problem (and it is dealt
with quite resonably), so we should have same approaches in both cases.
Honza
>
>
> r~