On 15 September 2015 at 21:58, Jim Grosbach <grosbach at apple.com> wrote:> That’s not quite accurate. It’s not A9+HDIV+VFP. It uses the A9 scheduling model, yes, but has its own completely distinct list of sub target features and such:Well, this is the target description in the TableGen files, and not exactly what I was talking about. when available, A9 has VFP3, while Krait has VFP4. Which brings the other side of the discussion, around the TargetParser, that the information in Clang is completely disconnected from the TableGen descriptions, but it's not relevant to the discussion.> Having the triple, or anything else outside this level of implementation details, refer to krait in terms of cortex-a9 is a problem.The Krait case is special, because GAS doesn't support it, so we have to use A9 + target-features or compilation breaks when using GAS. We're trying to get it in GAS, but it could take a while. When it does, we change it. But the ARM world is more complicated than that. Cores come in so many variations that it would be impossible to give a name to all of them, or more importantly, it would bloat our target descriptions to an unmanageable point. Having a way to access the target features at that level via a high-level target description is crucial to keep all that mess to a minimum, while still having a complete and sane implementation. Bottom line is, we can't create a name for each CPU+Arch+Features variations out there because of technical (bloat in LLVM, maintenance nightmare) and political (interaction with other tools and LLVM based products). cheers, --renato
> On Sep 16, 2015, at 3:15 AM, Renato Golin <renato.golin at linaro.org> wrote: > > On 15 September 2015 at 21:58, Jim Grosbach <grosbach at apple.com> wrote: >> That’s not quite accurate. It’s not A9+HDIV+VFP. It uses the A9 scheduling model, yes, but has its own completely distinct list of sub target features and such: > > Well, this is the target description in the TableGen files, and not > exactly what I was talking about. when available, A9 has VFP3, while > Krait has VFP4. > > Which brings the other side of the discussion, around the > TargetParser, that the information in Clang is completely disconnected > from the TableGen descriptions, but it's not relevant to the > discussion. > > >> Having the triple, or anything else outside this level of implementation details, refer to krait in terms of cortex-a9 is a problem. > > The Krait case is special, because GAS doesn't support it, so we have > to use A9 + target-features or compilation breaks when using GAS. > We're trying to get it in GAS, but it could take a while. When it > does, we change it.Why do we care about GAS? We have an assembler.> > But the ARM world is more complicated than that. Cores come in so many > variations that it would be impossible to give a name to all of them, > or more importantly, it would bloat our target descriptions to an > unmanageable point. Having a way to access the target features at that > level via a high-level target description is crucial to keep all that > mess to a minimum, while still having a complete and sane > implementation. > > Bottom line is, we can't create a name for each CPU+Arch+Features > variations out there because of technical (bloat in LLVM, maintenance > nightmare) and political (interaction with other tools and LLVM based > products). > > cheers, > --renato
On 16 September 2015 at 21:56, Jim Grosbach <grosbach at apple.com> wrote:> Why do we care about GAS? We have an assembler.It's not that simple. There are a lot of old code out there, including the Linux kernel which we do care a lot, that only compiles with GAS. We're slowly moving the legacy code up to modern standards, and specifically some kernel folks are happy to move up not only the asm syntax, but the C standard and move away from GNU-specific behaviour. But we're not quite there yet, and might not be for a few more years. so, yes, we still care about GAS. But this is not just about GAS. As I said on my previous email, this is about clearing the bloat in target descriptions by both: removing the need for adding numerous CPU names, target features, architecture names (xscale, strongarm, etc), AND making sure all parties (front/middle/back-ends) speak the same language, produced from the same source. The TargetTuple is that common language, and the TargetParser created from the TableGen files is the common source. The Triple becomes a legacy constructor value for the Tuple. All other target information classes are already (or should be) generated from the TableGen files, so the ultimate source becomes the TableGen description, which I think it what you were aiming to on your comment. For simple architectures, like x86, you don't even need a TargetParser. You can easily construct the Tuple from a triple and use the Tuple as you've always used the triple. No harm done. But for the complex ones like ARM and MIPS, having a common interface generated from the same place the other interfaces are is important to avoid more bridges between front and middle and back end interpretations of the same target. Whatever legacy ARM or MIPS carry can be isolated in their own implementation, leaving the rest of the targets with a clean and simple interface. cheers, --renato