[llvm-dev] The Trouble with Triples

[Daniel Sanders via llvm-dev]

If Triple is available then people will likely misuse it. Where sensible, I'd like it to have boundaries where it stops flowing and hands over to better representations in TargetMachine/MCTargetMachine/something-else.

> Rationalising the suggestion for cpu: While I fully agree that a mips- triple must be big endian default and mipsel-
> must be little endian there is nothing to stop an opposing endian ‘multilib’ in such a toolchain. That’s why I suggest
> that endian should not end up coming from the triple (internally in LLVM) for architectures that support both endians.

You're talking about the place to look for the information and not the origin of that information, right?
The initial value has to originate from the interpretation of the triple (plus customizations), there's nowhere else to get it.

From: Matthew Fortune
Sent: 24 September 2015 14:46
To: Daniel Sanders; Eric Christopher; Renato Golin; Jim Grosbach
Cc: llvm-dev at lists.llvm.org
Subject: RE: The Trouble with Triples

I think this all matches up with Eric’s comments. Personally I’d advocate getting to a point where the triple can flow through unmutated (because it becomes unused as a source of information that can be overridden) but it doesn’t matter much; there will be some extra data flowing alongside it for all the other implied or overridden settings. The useful bits of the triple become cpu family ‘mips’ (for any of mips, mipsel, mips64, mips64el, mips64orion, mips64octeon), OS ‘linux’ and environment ‘gnu’ (for any of gnu, gnuabi32, gnuabi64, gnueabihf etc).

Rationalising the suggestion for cpu: While I fully agree that a mips- triple must be big endian default and mipsel- must be little endian there is nothing to stop an opposing endian ‘multilib’ in such a toolchain. That’s why I suggest that endian should not end up coming from the triple (internally in LLVM) for architectures that support both endians.

I think we are done here. Just need an implementation to deal with the finer points; I’ll resist commenting further on this thread.

Thanks for the discussion everyone, it’s been quite educational.
Matthew

From: Daniel Sanders
Sent: 24 September 2015 14:18
To: Eric Christopher; Renato Golin; Jim Grosbach
Cc: llvm-dev at lists.llvm.org; Matthew Fortune
Subject: RE: The Trouble with Triples

> > > The word 'all' is what still bothers me here. If any one piece of the information is derived from incorrect information in the triple, then the behaviour will likely be incorrect.
> >
> > If it's possible to be derived from the triple then it's going to be correct or the triple is incorrect.
> > If it's something that's overridden later because it can't be represented by a triple then that
> > default needs to be overriden. This make sense? My mipsel example is what comes to mind here the most.
> I think so although the triple is often incorrect, particularly with Triple::mips/mips64.
>
> How's the triple incorrect? Is it user error, configuration error, or just doesn't represent the full value of the options the user may have specified?
It doesn't reflect the effects of the command line options but the backend believes it does.

It also conflates having a mips64 architecture with intending to use a mips64 architecture but these aren't quite the same thing. For example, 'mips-linux-gnu –mips64' means O32 on a MIPS64 which is effectively MIPS32 and O32 in terms of what the compiler is permitted to use. This is the main reason I want to separate the textual llvm::Triple from the understanding of what the llvm::Triple means. I want to be able to take an initial meaning and mutate it according to the options. This can be done in-place in the llvm::Triple by string substitution (and that's what –EL and –m64 do) but that's a rather ugly way to do it. The other reason I want to separate the two is that it provides a home for triple-related information that is implied by the triple but isn't textually present such as the default CPU that clang should use. The separation provides a good point to account for configure-time/run-time triple customization.
Additionally, Renato wants this separation because interpreting ARM triples is hard and he needs somewhere to store the interpreted meaning.

Similarly, the backend also believes that Triple::mips implies O32 and Triple::mips64 implies N64 (N32 isn't represented) but we already have a plan to sort that out.

> Sounds like it was a bug that was fixed. :) That's pretty crazy though.

That's how I see it. The endian mismatch wasn't even the weirdest thing about it.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150924/0eaafe3f/attachment.html>