<div dir="ltr">Let's take a step back here.<div><br></div><div>It appears that you and Daniel are trying to solve some problems. I think solving problems is good, I just want to make sure that we're solving them in a way that gets us a decent API at the end. I also want to make sure we're solving the right problems.</div><div><br></div><div>TargetTuple appears to be related to the TargetParser as you bring up in this mail. They're two separate parts of similar problems - people trying to both serialize command line options and communication from the front end to the backend with respect to target information.</div><div><br></div><div>This leads me to a question: What can't be done to TargetMachine to avoid this serialization?</div><div>And a followup question: What can't be serialized at the function level in the IR to make certain things clear that aren't global? We already do this for a lot of command line options.</div><div>And one more: What global options do we need to consider here?</div><div><br></div><div>The goal of the configuration level of the TargetMachine is that it controls things that don't change at the object level. This is a fairly recently stated goal, but I think it makes sense for LLVM in general. TargetSubtargetInfo takes care of everything that resides under this (as much as possible, some bits are still in transition, e.g. TargetOptions). This is part of my suggestion to Daniel about the problems with MCSubtargetInfo and the assembler. Targets like Mips and ARM were unfortunately designed to change things on the fly during assembly and need to collate or at least change defaults as we're processing code. I definitely had to deal with a lot of the pain you're talking about when I was rewriting some of the handling there during the TargetSubtargetInfo work.</div><div><br></div><div>Now a bit more on TargetParser + TargetTuple:</div><div><br></div><div><span style="font-size:13.2px;line-height:19.8px">TargetParser appears to be trying to solve the parsing in Triple in a nice way for ARM and also some of the "what kind of subtarget feature canonicalization can we do in llvm that makes sense to communicate to the front end". I like this particular idea and have often wanted a library of feature handling, but it seems to have stabilized at an ARM specific set of code with no defined interface. I can't even figure out how I'd use it in lib/Basic right now for any target other than ARM. This isn't a condemnation of TargetParser, but I think it's something that needs to be thought through a bit more. It's been hooked up well before I'd expected it to and right now if we moved it to the ARM backend from Support it'd make just as much sense as it does where it is now other than making clang depend on the ARM backend as well as the X86 backend :)</span><br></div><div><span style="font-size:13.2px;line-height:19.8px"><br></span></div><div><span style="font-size:13.2px;line-height:19.8px">Right now I see TargetTuple as trying to take over all of the various arguments to TargetMachine and encapsulate them into a single thing. I also don't see this is bad, but I also don't see it taking all of them right now and I'm not sure how it solves some of the existing problems with data sharing that we've got which is where the push back you're both getting is coming from here. Ultimately library-wise I can agree with some of the directions you're headed - I just don't see the unification and interactions right now.</span></div><div><span style="font-size:13.2px;line-height:19.8px"><br></span></div><div><span style="font-size:13.2px;line-height:19.8px">As a suggestion as a way forward here let's see if we can get my questions above answered and also show some of how the interactions between llvm's libraries are going to get fixed, moved to a better place, etc here.</span></div><div><span style="font-size:13.2px;line-height:19.8px"><br></span></div><div><span style="font-size:13.2px;line-height:19.8px">Thanks!</span></div><div><span style="font-size:13.2px;line-height:19.8px"><br></span></div><div><span style="font-size:13.2px;line-height:19.8px">-eric</span></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 16, 2015 at 3:02 PM Renato Golin <<a href="mailto:renato.golin@linaro.org">renato.golin@linaro.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 16 September 2015 at 21:56, Jim Grosbach <<a href="mailto:grosbach@apple.com" target="_blank">grosbach@apple.com</a>> wrote:<br>
> Why do we care about GAS? We have an assembler.<br>
<br>
It's not that simple.<br>
<br>
There are a lot of old code out there, including the Linux kernel<br>
which we do care a lot, that only compiles with GAS. We're slowly<br>
moving the legacy code up to modern standards, and specifically some<br>
kernel folks are happy to move up not only the asm syntax, but the C<br>
standard and move away from GNU-specific behaviour. But we're not<br>
quite there yet, and might not be for a few more years. so, yes, we<br>
still care about GAS.<br>
<br>
But this is not just about GAS.<br>
<br>
As I said on my previous email, this is about clearing the bloat in<br>
target descriptions by both: removing the need for adding numerous CPU<br>
names, target features, architecture names (xscale, strongarm, etc),<br>
AND making sure all parties (front/middle/back-ends) speak the same<br>
language, produced from the same source.<br>
<br>
The TargetTuple is that common language, and the TargetParser created<br>
from the TableGen files is the common source. The Triple becomes a<br>
legacy constructor value for the Tuple. All other target information<br>
classes are already (or should be) generated from the TableGen files,<br>
so the ultimate source becomes the TableGen description, which I think<br>
it what you were aiming to on your comment.<br>
<br>
For simple architectures, like x86, you don't even need a<br>
TargetParser. You can easily construct the Tuple from a triple and use<br>
the Tuple as you've always used the triple. No harm done. But for the<br>
complex ones like ARM and MIPS, having a common interface generated<br>
from the same place the other interfaces are is important to avoid<br>
more bridges between front and middle and back end interpretations of<br>
the same target. Whatever legacy ARM or MIPS carry can be isolated in<br>
their own implementation, leaving the rest of the targets with a clean<br>
and simple interface.<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div>