[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