Tim Northover via llvm-dev
2016-Jan-05 10:28 UTC
[llvm-dev] Diff to add ARMv6L to Target parser
On 5 January 2016 at 09:13, Renato Golin <renato.golin at linaro.org> wrote:> Anyhow, Artyom's proposal is the best, IMO, to treat it like an alias > and handle like v7A internally. If we end up needing specific > decisions in the driver, it should stay in the driver.That's rather a hack, given that the 'l' actually has semantic meaning, but I suppose I could live with it. Tim.
Renato Golin via llvm-dev
2016-Jan-05 10:55 UTC
[llvm-dev] Diff to add ARMv6L to Target parser
On 5 January 2016 at 10:28, Tim Northover <t.p.northover at gmail.com> wrote:> That's rather a hack, given that the 'l' actually has semantic > meaning, but I suppose I could live with it.Not really. Today, all platform decisions are in the Triple class, which is known to be insufficient. Until the Tuple class replaces the Triple for such uses, we'll have to continue on the same implementation, which is to set up a triple and a lot of other independent flags which convey the original idea. In the Arch side, ARMv7l is *really* ARMv7A, so it should not have any further knowledge about the rest of the environment. Ideally, the driver should set up a Tuple object with all the decisions, using the TargetParser *only* to map from text to enum, and using those values to get a complete picture, also based on the environment, etc. Once Tuple holds all the info, we can have other enum values to mean all other environmental options, but none of them should be in the Arch portion. cheers, --renato
Tim Northover via llvm-dev
2016-Jan-05 11:40 UTC
[llvm-dev] Diff to add ARMv6L to Target parser
On 5 January 2016 at 10:55, Renato Golin <renato.golin at linaro.org> wrote:> On 5 January 2016 at 10:28, Tim Northover <t.p.northover at gmail.com> wrote: >> That's rather a hack, given that the 'l' actually has semantic >> meaning, but I suppose I could live with it. > > Not really.I disagree. "armv7l" is created specifically by Linux appending a little-endian 'l' to an "armv7" base. It's much less common (because no-one cares about big-endian), but "armv7b" also exists. As do "armv6l", "armv6b" and probably "armv8" equivalents too if you ran a 32-bit kernel there. Adding random aliasing on an ad-hoc basis doesn't scale or represent what's really going on.> In the Arch side, ARMv7l is *really* ARMv7A, so it should not have any > further knowledge about the rest of the environment.What does RTLinux on an R-class CPU present itself as? My guess would be "armv7l" too. I'm not too concerned about deciding that we only care about A-class Linux, but I am concerned about taking an unprincipled approach to the l/b suffix. Not enough that I can't live with it though. As you say this whole area's enough of a mess already, one more bit isn't going to break the world. Cheers. Tim.