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

[David Tweed]

The example I was giving was a "thinly generalized" version of the
devirtualisation issue: what was happening was that a destructor, which on
ARM ABI is returns "this", was being devirtualised and a function with the
return type of the base class prototype was being added whereas it ought to
have been the return type of the actual function being inlined. (Devirt
can't do general covariant returns, but I gather that no-one actually uses
destructor return types anyway.) On x86_64 the return type of a destructor
is always void, so getting the type from the base class prototype gives the
same result. I know it's a matter of semantics: was that code actually "a
latent bug" on x86_64 when it would always be guaranteed to produce the
right code (on that platform)?

I know this is a ridiculously specific example, and I don't know if similar
effects can happen elsewhere, I just have this feeling that picking the
simplest platform it's more likely for stuff to pass even if there's a
minor latent issue. But I can't back that up with any facts.

As for proposed solutions, I can't say I really have anything that counts
as a solution. I think I need to see what "unknown" actually implies in
terms of behaviour/code-paths, it's just that if it's equivalent to "the
simplest, most vanilla target" it may be less effective in finding issues.
But again, that's just a feeling.

Regards,
Dave


On Mon, Dec 3, 2012 at 6:59 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Mon, Dec 3, 2012 at 9:21 AM, David Tweed <david.tweed at arm.com> wrote:
> > -----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;
>
> Sorry, I think I lost track of this example around here. What do you
> mean by "getting the type from the wrong place"?
> What sort of solution are you proposing?
>
> What I think we're discussing here is:
> All tests without a triple be written in such a way as to pass for any
> triple (& there would be test infrastructure to help ensure this) &
> that the default would be a fixed "unknown" triple, or an arbitrary
> (but constant/singular) concrete triple.
>
> What is it you have in mind?
>
> >  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
> >
> >
> >
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>



-- 
cheers, dave tweed__________________________
high-performance computing and machine vision expert: david.tweed at gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121204/632cef51/attachment.html>