[LLVMdev] [cfe-commits] [PATCH/RFC, PowerPC] Extend 32-bit function arguments / return values

Chandler Carruth chandlerc at google.com
Mon Oct 22 11:53:54 PDT 2012

So, I'm not really sure if this is the right approach. I'd like some
folks from the LLVM side of things to chime in.

In general, I'm not certain we want to continue growing our dependence
on the signext and zeroext attributes on return types, or whether we
want to do the extension in the frontend instead.

Most of the targets in Clang currently eagerly zext or sext the return
value to make it conform to the ABI. You can look at some of the other
classify*Type methods in Clang for how.

On Mon, Oct 22, 2012 at 11:23 AM, Rafael EspĂ­ndola
<rafael.espindola at gmail.com> wrote:
>> Unfortunately, this change also causes about 20 spurious regression test
>> failures on PowerPC, since IR output now frequently (i.e. for plain "int"
>> types) contains an extra "signext" attribute, which throws off strict
>> text-matching in various tests.  I've fixed those by optionally accepting
>> "signext" (or "zeroext" as the case may be) via a regexp.   Not sure if
>> this is really the best way of handling this ...
> Not sure as well. It looks easy to forget to add this to new tests and
> break a ppc64 bot. What abound adding some -triple=  to the tests?
> LGTM with that change if you are ok with it. Just give it a day to see
> if anyone else has another idea.

I'd vote for not adding optional matching to the tests. Instead, we
should specify an exact triple and match the expected IR exactly.
However, let's figure out what the IR should look like first.

>> To simplify review, I've attached two patches, one with the actual fix (and
>> a new test for it), and one that contains all the signext/zeroext test
>> changes.
>> Would this be OK to commit?
>> Bye,
>> Ulrich
> Cheers,
> Rafael
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

More information about the llvm-dev mailing list