[PATCH 01/14] Initial create of rs6000-genbif.c.

Bill Schmidt wschmidt@linux.ibm.com
Tue Feb 4 22:44:00 GMT 2020


On 2/4/20 4:36 PM, Segher Boessenkool wrote:
> On Tue, Feb 04, 2020 at 03:10:32PM -0600, Bill Schmidt wrote:
>>> I really don't think using the new acronym "bif" helps; built-in
>>> functions already are often called "builtins" (or "intrinsics", which is
>>> problematic itself).
>> Until we manage to replace the old methods, we already have
>> rs6000-builtin.def, so I am a bit constrained in my choices. Given that
>> restriction, what name would you prefer?  I can use rs6000-builtins.def
>> (the plural) if you like.
> As we discussed (offline), maybe rs6000-builtin-new.def is best (and at
> the end of this conversion, just move it).
+1
>
>>>> +     ldv     Needs special handling for vec_ld semantics
>>>> +     stv     Needs special handling for vec_st semantics
>>> Call those "vec_ld" and "vec_st", then?  Or should I get used to it, the
>>> names aren't obvious, but cut-and-paste always is ;-)
>> Hm.  Well, vec_ld is a specific built-in, but this applies to a few more
>> than just that one.  But sure, if you want.
> "ldv" certainly is shorter and nicer in principle, but it is a bit
> cryptic.  As I said, it's probably not too hard to get used to it; and
> maybe a better name will present itself?
Maybe ldvec and stvec would serve without introducing specific builtin 
confusion.
>
>>>> +[TARGET_ALTIVEC]
>>> Can this be a C expression?  Most gen* programs just copy similar things
>>> to the generated C code, which can be interesting to debug, but works
>>> perfectly well otherwise.
>> I rather prefer the way it is.  I do generate C code from this in the
>> subsequent patches.  But I like table-driven code to use things that
>> look like tables for input. :-)
> That's not what I meant...  Can you say
>    [TARGET_ALTIVEC && TARGET_64BIT]
> here?  Or even just
>    [!TARGET_ALTIVEC]
> or
>    [1]
> for always, or
>    [0]
> for never ("commented out").
Ah!  Sorry for misunderstanding.  Right now just an identifier is 
allowed, but we could certainly grab the whole string between the [] and 
drop it in with no concerns.  Hopefully we both remember when we get to 
the patch that reads the stanzas...
>
>>>> +  Blank lines may be used as desired in these files.
>>> Between stanzas and stuff only?  There are places where newlines are
>>> significant and not just whitespace, right?
>> I don't believe so, although there may be places where I forgot to allow
>> a line to be advanced -- that would be a bug, though, so let me know if
>> you see any.  Blank lines don't have any inherent meaning in the input
>> files.
> Not blank lines, I'm asking about newlines :-)  But those are not allowed
> to be inserted just anywhere, a line has to be one line, iiuc?

Yes.  Additional newlines can follow a newline, but the individual lines 
must contain everything that's expected in them.

Bill

>
>
> Segher



More information about the Gcc-patches mailing list