[patch] Start fixing pr24429

[Saleem Abdulrasool via llvm-commits]

On Wednesday, August 12, 2015, Dan Gohman via llvm-commits <
llvm-commits at lists.llvm.org
<javascript:_e(%7B%7D,'cvml','llvm-commits at lists.llvm.org');>> wrote:

> On Wed, Aug 12, 2015 at 8:01 AM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
> > On 12 August 2015 at 10:55, Dan Gohman <dan433584 at gmail.com> wrote:
> >> I don't understand the vision for triples well enough to properly
> >> review this. Is there an eventual boundary for the information that
> >> should be sourced from a triple? I read the recent "trouble with
> >> triples" thread but am still not fully clear on where things are
> >> headed.
> >
> > I am not sure, but note that this patch doesn't add any new
> > information to the triple. I just uses what is already there.
>
> It does remove information from MCObjectFileInfo though. Is it really
> desirable to pick the Triple to be the one that gets to keep this
> information, rather than the other way around? I don't have a clear
> view of where this is headed.


I think the decision to keep it in the triple is sound.

Although from an abstraction POV, the MOFI should know about the format
(see my comment about not thinking that the enumeration belongs in the
Triple), it is more reasonable to simply store it in the triple.  The
triple needs to understand the target object format since it may be part of
the triple (e.g. windows-elf).  The triple is almost universally available,
making it easier to query at various places.  Finally, although the MOFI
had this information, it was derived from the triple - the source of truth.

The information in MOFI was duplicating the information in the triple.  Why
not pass it along?

Now, I could be convinced that keeping the interface in MFOI and making it
a means of querying the triple is just as valid.  But, that gives you two
ways to accomplish the same thing.  I think that this would also solve the
issue, but is it really better to have multiple ways to query this?

>From the "trouble with triples" thread, it seemed that the idea was to have
some generic collection of key/value pairs (converting the triple into a
tuple).  This information could easily map into that view, if this
information is kept in the triple.

Dan
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150812/c39d268c/attachment.html>