[LLVMdev] [cfe-dev] RFC: Change tests to run with fixed (not-host dependent) triple

David Tweed david.tweed at arm.com
Mon Dec 3 09:21:58 PST 2012


-----Original Message-----
From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On
Behalf Of David Blaikie
Sent: 03 December 2012 16:41
To: Renato Golin
Cc: LLVM Developers Mailing List; cfe-dev
Subject: Re: [cfe-dev] [LLVMdev] RFC: Change tests to run with fixed
(not-host dependent) triple

>> c. If there is some reason that running with an "unknown" host triple is
>> undesirable, I propose that we set the default test triple to be
>> "x86_64-pc-linux-gnu", and require deviations to be specified.
>
> Here, I don't agree. I don't see why one platform should be the
> default over another.

| Because we would need/want a default of some kind. The argument here
| is: "If we can't choose some agnostic default for all tests, we should
| choose a non-agnostic default" - the only alternative position is that
| we don't choose a default but instead force every test to specify an
| arbitrary triple. I don't think this is substantially more valuable,
| though it is the current state of affairs among the tests that do have
| triples specified (that they are "random" in the sense that they're
| usually whatever architecture the developer is working on at the time
| - so we have lots of linux ones, lots of darwin ones, and a smattering
| of ARM)

Just a point here: the reason I'd mildly prefer not to have a default that
avoids as much target dependent stuff as possible is that it's generally
going to have a higher probability of passing even if something is "wrong"
in the sense that, eg, if the return type of some thing is ABI mandated to
be void, then you could be getting the type from the wrong place and still
pass since all places give the same result; if you happen to be doing this
on an ABI where the where the value differs depending where it is obtained
from then you'll probably catch errors that are "latent errors" for the
simpler ABI. (Yes, this is a thinly disguised version of the
devirtualisation issue, but I do think this phenomenon may apply elsewhere:
the less complicated an ABI the more chance that something "slightly wrong"
will actually pass.) Those are my thoughts anyway.

Regards,
Dave







More information about the llvm-dev mailing list