similar to: [LLVMdev] [RFC] Conditional RegClass membership

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

Thanks for the clarifications, Bob! I’ve spent some time with the head of the llvm.org repo, and I now understand a lot better what Renato and Tim 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

> 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

Thank you very much for the references, we've missed this discussion from last week. Seeing that the RFC hasn’t got any new responses since Wed 12th, is now the time to declare that the community has accepted the proposal, and to update the docs? Or is there any formal deadline for objections to be raised? -----Original Message----- From: meinersbur at googlemail.com [mailto:meinersbur at

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:

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

Hi, I have a question about the definitions of t2LDRSB and t2LDRSB_PRE in ARMInstrThumb2.td : I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case, because of some register hint that is being enforced?

This buildbot seems to have been failing for a while (though it's hard for me to identify the root cause in the logs, as I mentioned in another thread, so it's hard to say if it's the same failure, or if the failure is consistent, etc) - anyone watching it/caring aobut it? ---------- Forwarded message ---------- From: <llvm.buildmaster at lab.llvm.org> Date: Wed, Sep 30, 2015 at

Hello, http://llvm.org/docs/GettingStarted.html#software lists "GCC >=4.7.0" among requirements for building LLVM. However, my attempt of building LLVM+Clang with gcc 4.7.3 has failed with a multitude of errors, such as: lib/LTO/Caching.cpp:74:7: error: looser throw specifier for 'virtual llvm::lto::localCache(std::string, llvm::lto::AddFileFn)::<lambda(unsigned int,

>> However, because the DefaultTargetTriple is armv6l-unknown-linux-gnueabihf, >> and llvm didn’t know about v6l, it would fail to match and canonicalize to armv6. >> I added the notion of v6l to llvm to address this. > > ARMv6l was definitely there once. I'm not sure what happened. > > I'm copying the ARM folks that did most of the recent changes in hope

I'm looking at an issue where we want a particular pseudo-instruction to choose from a set of registers that is not included in the existing set of RegisterClass definitions. More concretely, there is a RegisterClass in ARMRegisterInfo.td defined as def rGPR : RegisterClass<"ARM", [i32], 32, (sub GPR, SP, PC)> { let AltOrders = [(add LR, rGPR), (trunc rGPR, 8)]; let

Jim, Thanks for the hints. Does LLVM allow allocation of the same register across register classes? For example, in the ARM backend, can an instruction write to R0 when it is part of register class tGPR, but then use R0 in the next instruction as a source register from the rGPR class? If LLVM can do this, then this will work. Micah > -----Original Message----- > From: Jim Grosbach

On May 26, 2014, at 8:21 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Mon, May 26, 2014 at 7:41 PM, Andrew Trick <atrick at apple.com> wrote: > On May 26, 2014, at 5:02 PM, Chandler Carruth <chandlerc at google.com> wrote: > >> >> On Mon, May 26, 2014 at 4:43 PM, Andrew Trick <atrick at apple.com> wrote: >> This has been

Hi Micah, You can just create a new register class that only contains the registers you want and use that for the instruction. The set theoretic operators for register class definition make this very easy. See the ARM backend definitions of GPRnopc, rGPR, etc.. for examples. -Jim On Aug 16, 2011, at 9:18 AM, Villmow, Micah wrote: > Is there a way in tablegen to specify that a certain

Hi Junbum, > I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case, because of some register hint that is being enforced? They're not allocated during CodeGen because of the Reserved.set(…) calls in

I'm trying to implement the standalone assembler for mips and I have encountered a problem in instruction operands matcher. In mips instruction set there are math instructions with two format flags in the mnemonic, one for source and one for destination register. For example ceil.w.s means both source and destination are F32 registers while ceil.l.d means both source and destination are F64

Hi all, My understanding is that we keep around KILL instructions in order to keep the results of the various register liveness analysis passes valid. Consider for example the following machine basic block: BB#0: derived from LLVM BB %entry Live Ins: %A0_64 %A1_64 %V0_64<def> = AND64 %A0_64<kill>, %A1_64<kill> %V0<def> = KILL %V0,

On May 22, 2012, at 8:05 AM, "Medic, Vladimir" <vmedic at mips.com> wrote: > I'm trying to implement the standalone assembler for mips and I have encountered a problem in instruction operands matcher. > In mips instruction set there are math instructions with two format flags in the mnemonic, one for source and one for destination register. > For example ceil.w.s

Is there a way in tablegen to specify that a certain instruction can only be allocated with a certain subset of a register class? Thanks, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110816/329bea6e/attachment.html>

Hi I want to cross-compile llvm  for  arm board , running llvm on  Ububtu Server 11.04  x86_64  thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111017/178ae8fe/attachment.html>