search for: targetparser

...sed for both arm > and aarch64. For the actions I mentioned above,I wrote a check function as below, basing on the naming rules of the arm architecture. +//Only if -march startwith "armv" or "v" or "iwmmxt" or "xscale",it can be seen valid and sended to TargetParser +//for further parsing +static bool checkArchValid(StringRef Arch) +{ + if ((Arch.startswith("armv")) || Arch[0] == 'v' || + (Arch.startswith("iwmmxt")) || (Arch.startswith("xscale"))) + return true; + return false; +} I just do a simple check in...

On 9 March 2015 at 18:21, Reid Kleckner <rnk at google.com> wrote: > To be clear, TargetParser is about parsing subtarget CPUs and features, > right? In the first stage, yes. But there's a lot more. I hope this ends up being a much larger infrastructure to query for target support, not just parsing strings (which we can cope with duplication), but defining architectural behaviour, wh...

...AArch32? I guess we could use the triple (which has aarch64 or arm in it), but then it will need the triple or else we'll have a problem, since the current interpretation of "armv8a" is AArch32. > Personally I’m in favor of having that be rejected, it would be good to have > TargetParser/Clang generally reject CPUs/architectures that are not valid or > don’t add information as opposed to converting them to a fairly arbitrary > choice (that will and does only cause confusion). Rejecting that on -march is independent than rejecting that in the target parser. I think the logic...

Hi everyone, I'm a member engineer of linaro's llvm team,coming from Spreadtrum.I am a new person on LLVM.Now I'm writing a Target Parser for AArch64,so options parsing of AArch64 about cpu & arch & fpu can be summary to one place. In the TargetParser,we assume "aarch64" and "arm64" are synonyms of armv8a(as they are only for armv8a,people usually do this). So after using AArch64TargetParser in options parsing in Clang,using "-march=aarch64" and "-march=arm64" are both valid. I saw Kevin has a different v...

Hi Folks, I'm back looking at the target parser that we discussed last year, and I have some questions. http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-August/038699.html There is no way I can create a target-independent parser in lib/Target without re-encoding all the information about the targets that we already have in the table-gen files on all targets' directories. Doing that would

...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 we...

On 9 March 2015 at 17:40, Renato Golin <renato.golin at linaro.org> wrote: > The only way I can think of solving this is to change how tablegen() > handles the file name, with some "if(IS_ABSOLUTE)", but looking > further, the file name is used to more than just a filename, and gets > included in some variables names, etc. Also, I can't add another > option to

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

...-dev at lists.llvm.org>> wrote: Hi everyone, I'm a member engineer of linaro's llvm team,coming from Spreadtrum.I am a new person on LLVM.Now I'm writing a Target Parser for AArch64,so options parsing of AArch64 about cpu & arch & fpu can be summary to one place. In the TargetParser,we assume "aarch64" and "arm64" are synonyms of armv8a(as they are only for armv8a,people usually do this). So after using AArch64TargetParser in options parsing in Clang,using "-march=aarch64" and "-march=arm64" are both valid. I saw Kevin has a different v...

...m were talking about re. the architecture aliases. The patch to add v6l, therefore, seems simple enough. I haven’t been able to test it in my usual flow, because that involves the whole swift stack. I’m considering creating a program that links to llvm to test the behavior. Index: lib/Support/TargetParser.cpp =================================================================== --- lib/Support/TargetParser.cpp (revision 257090) +++ lib/Support/TargetParser.cpp (working copy) @@ -401,6 +401,7 @@ .Case("v5", "v5t") .Case("v5e", "v5te") .Case(&...

On 10 March 2015 at 16:20, Mehdi Amini <mehdi.amini at apple.com> wrote: > I’d like to avoid as much as possible adding compilation time to the process unless it is necessary (I’m not saying it does not worth it here). As I said in the review, it may end up being faster, because of the amount of crap we'll remove from all tools and LLVM. > It is not clear to me why do you need

...--|-----|---------| Examples of each of these can be found at the end of this document. Problems With the Current Options --------------------------------- - You cannot select all extensions through an assembly directive, since the AsmParser's list is a separate subset of the complete one in TargetParser. - Combinations of options are not checked for compatibility. - Many extensions are tied to their base architecture, though it is valid to add them individually to a previous v8.x-a architecture. - Users need to work out what FPU they need for ARM, this should be implied by the selected arch and ex...

...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 speci...

...-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...

...--|-----|---------| Examples of each of these can be found at the end of this document. Problems With the Current Options --------------------------------- - You cannot select all extensions through an assembly directive, since the AsmParser's list is a separate subset of the complete one in TargetParser. - Combinations of options are not checked for compatibility. - Many extensions are tied to their base architecture, though it is valid to add them individually to a previous v8.x-a architecture. - Users need to work out what FPU they need for ARM, this should be implied by the selected arch and ex...

Hi Eli, Renato, Thanks for your feedback, there's a lot more to some of these things than I knew. I've addressed your points below. The overall summary is: - Start with converting the TargetParser to tableGen, with no user facing changes - Add warnings based on that, behind -Wall. Starting with command lines, since directives have larger implications that need investigation Thanks, David Spickett. mandatory features ================== >> Could you go into a bit more detail about ma...

...pears 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. 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. This leads me to a question: What can't be done to TargetMachine to av...

...s 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...

...s "ARMv7A big endian". I believe it's what any Linux kernel will present itself as via "uname -a" which, as James said, is a vaguely sane way to seed a triple. > The ARM documents define a list of official architecture names, and > those are the ones supported by the TargetParser. What the > Triple/Tuple supports is completely orthogonal. I do know this, Renato. > So, in the TargetParser, there can be no "ARMv7L" nor "ARMv7B", only > "ARMv7A". The other strings map to ARMv7A because that's what they > generally mean, in the wi...

...--|-----|---------| Examples of each of these can be found at the end of this document. Problems With the Current Options --------------------------------- - You cannot select all extensions through an assembly directive, since the AsmParser's list is a separate subset of the complete one in TargetParser. - Combinations of options are not checked for compatibility. - Many extensions are tied to their base architecture, though it is valid to add them individually to a previous v8.x-a architecture. - Users need to work out what FPU they need for ARM, this should be implied by the selected arch and ex...