search for: armtargetparser

...ples and compiler options such as -EL/-EB, -m32/-m64, etc. and these will be reflected in the internal LLVM tuple. Ok, so that will probably involve the Triple / Parser refactoring I'm doing. Right now, Triple handles some of that, but it's not authoritative not final. I've created an ARMTargetParser class that deals with parsing arch/cpu/fpu strings, and I'm moving all string parsing in Clang (LLVM is done already) to it. We may also have to move llc, lli and others. Once this is done, we can begin to move more logic to the Triple in the same way, and let target specific Triple management...

...EL/-EB, -m32/-m64, etc. and these will be reflected in the internal LLVM > > tuple. > > Ok, so that will probably involve the Triple / Parser refactoring I'm doing. > > Right now, Triple handles some of that, but it's not authoritative not > final. I've created an ARMTargetParser class that deals with parsing > arch/cpu/fpu strings, and I'm moving all string parsing in Clang (LLVM > is done already) to it. We may also have to move llc, lli and others. > > Once this is done, we can begin to move more logic to the Triple in > the same way, and let target sp...

Oops, I neglected to reply-all…. The current stable branch at github still has it: https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106 <https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106> Should I get the head of the non-swift repository and generate a new diff? Also, I suspect that it’s not a good idea to have armv6l map to armv6k, because that seems like quite an assump...

> You assume triples make sense. That's the first mistake everyone does > when thinking about triples. :) I know they don't make sense in many corner cases, but I think discarding logic where it *does* exist is a mistake. > AFAIK, "ARMv7B" is only used by HighBank, which is no more. But that, > too, was "ARMv7A big endian". I believe it's what any

...;william at housedillon.com <mailto:william at housedillon.com>> wrote: >>> Oops, I neglected to reply-all…. >>> >>> The current stable branch at github still has it: >>> >>> https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106 <https://github.com/apple/swift-llvm/blob/stable/include/llvm/Support/ARMTargetParser.def#L106> >>> >>> Should I get the head of the non-swift repository and generate a new diff? >>> >>> Also, I suspect that it’s not a good idea to have armv6l ma...

Taking the suggestions of the group under consideration, I’ve generated a new diff. The thing to note is that armv6l is now treated identically to armv6hl. I’ve also added a unit test. This seems to me to be the least invasive method, and holds to existing conventions as closely as possible. Thoughts? -------------- next part -------------- A non-text attachment was scrubbed... Name:

.../llvm/llvm-master/include/llvm/MC/MCStreamer.h:30:0, from external/llvm/llvm-master/lib/Object/RecordStreamer.h:16, from external/llvm/llvm-master/lib/Object/ModuleSymbolTable.cpp:17: external/llvm/llvm-master/include/llvm/Support/TargetParser.h:61:31: fatal error: ARMTargetParser.def: No such file or directory Any direction would be greatly appreciated: Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180805/952fb16d/attachment.html>

>> Going back through SVN history, I cannot find any evidence that ARMv6L ever existed. > > Oh, my bad!! I was thinking of ARMv7l... :/ > > Nevertheless, I'll leave you guys to review this one, as I lost touch with the parser a while ago. Ah, I see: ARMv7L is now an alias for ARMv7A. So, if William has to add support for ARMv6L, I'd suggest he adds it as an alias, and

...ple, let's say John Smith > with the SSN Y also answers to the name Rameses. This is the problem that > Renato is working on. Renato needs to be able to see the name Rameses and > map this to the correct John Smith (or at least someone very much like him). > This is the gist of what ARMTargetParser is/was doing. A good example is "krait", a CPU design from Qualcomm. Krait used to be mapped to Cortex-A15 because it has VFP4 and HDIV, but architecturally, it is a lot closer to a Cortex-A9 than an A15. So assuming that Krait == A15 means making a lot of bad optimisation decisions in...

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote: > This is the key question. The LLVM assumption is that these sorts of things > are inferable from the triple. Your observation here that the GNU world’s > notion of triples and LLVM’s need not be the same is a good one. Having a > split and a translation up in clang seems an interesting avenue to explore. >

2017-05-26 17:47 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>: > Changing a header file somewhere and having to spend 10 minutes waiting > for a build leads to a lot of wasted developer time. > > The real culprit here is tablegen. Can we split support and ADT into two > - the parts that tablegen depends on and the parts that it doesn't? >

...> Timer.h > TrailingObjects.h > Unicode.h > UnicodeCharRanges.h > UniqueLock.h > Watchdog.h > Win64EH.h > WindowsError.h > xxhash.h > > > Narrowly useful stuff: > AArch64TargetParser.def > ARMAttributeParser.h > ARMBuildAttriubtes.h > ARMEHABI.h > ARMTargetParser.def > ARMWinEH.h > Binary*Stream*.h > BlockFrequency.h > BranchProbability.h > CachePruning.h > CBindingWrapping.h > CodeGen.h > CodeGenCWrappers.h > COFF.h > Compression.h > DebugCounter.h > DotGraphTraits.h > Dwarf.def > Dwarf.h > DynamicLibrary.h >...

...> Timer.h > TrailingObjects.h > Unicode.h > UnicodeCharRanges.h > UniqueLock.h > Watchdog.h > Win64EH.h > WindowsError.h > xxhash.h > > > Narrowly useful stuff: > AArch64TargetParser.def > ARMAttributeParser.h > ARMBuildAttriubtes.h > ARMEHABI.h > ARMTargetParser.def > ARMWinEH.h > Binary*Stream*.h > BlockFrequency.h > BranchProbability.h > CachePruning.h > CBindingWrapping.h > CodeGen.h > CodeGenCWrappers.h > COFF.h > Compression.h > DebugCounter.h > DotGraphTraits.h > Dwarf.def > Dwarf.h > DynamicLibrary.h >...

> > The Triple object will remain unchanged. > > The Tuple will be the API to handle getting/setting parameters > depending on the Triple, compiler flags, attributes, etc. > > This part doesn't seem obvious from the direction the patches are going. > There will be no string representation of all options, as that would > be impossible, or at least, highly

Hi, In http://reviews.llvm.org/D10969, Eric asked me to explain the wider context of the TargetTuple object that was replacing Triple on llvmdev so here it is. Before I start, I'm sure I don't know the full extent of GNU triple ambiguity and lack of canonicity. Additional examples are welcome. The Problem As you know, LLVM uses a GNU Triple is as a target description that can be relied