similar to: [LLVMdev] Liveness information still usable after register allocation?

Hi, I have ported LLC to a risc cpu. It can pass benchmark that I have at current. But I want do some optimization after register alloction by adjusting register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. R4 is marked <kill> at MBB0. If I scan R4's

I am looking at results from analyzePhysReg, and am getting results a little different than I expected for x86. The call to this is coming from this code in llvm::MachineBasicBlock::computeRegisterLiveness 1163 MachineOperandIteratorBase::PhysRegInfo Analysis = 1164 ConstMIOperands(I).analyzePhysReg(Reg, TRI); The instruction I being analyzed is: %BX<def> = MOV16rm

Jim/Tim/Renato, A few days ago (has it been weeks now?) we discussed a codegen problem on armv4t having to do with lo->lo register copies. I'd like to start that discussion again, this time with a patch. A brief summary of the problem for folks who didn't catch the discussion earlier, and those like me who forget what they ate for breakfast: ;] The mov instruction on armv4t

>-----Original Message----- >From: Quentin Colombet [mailto:qcolombet at apple.com] >Sent: Thursday, December 03, 2015 4:43 PM >To: Smith, Kevin B <kevin.b.smith at intel.com> >Cc: llvm-dev at lists.llvm.org >Subject: Re: [llvm-dev] analyzePhysReg question > > >> On Dec 3, 2015, at 4:35 PM, Smith, Kevin B via llvm-dev <llvm- >dev at lists.llvm.org>

On Jan 14, 2010, at 6:39 PM, 任坤 wrote: > But I want do some optimization after register alloction by adjusting > register using. I scan MachineBasicBlock to analyze operand's IsKill, IsDead , IsDef attribute to get a physical register's liverange. But I get a strange case at MBB.jpg. You can also look at RegisterScavenging.cpp and MachineVerifier.cpp. They are doing the same

> On Dec 3, 2015, at 5:36 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Dec 3, 2015, at 5:11 PM, Smith, Kevin B <kevin.b.smith at intel.com <mailto:kevin.b.smith at intel.com>> wrote: >> >> >> >>> -----Original Message----- >>> From: Quentin Colombet [mailto:qcolombet at apple.com

It is $target dependent. I’m curious what makes you think it is $host dependent. Thanks, Taewook On 3/3/17, 5:10 PM, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote: On 3/3/17 12:23 PM, Taewook Oh wrote: > Thanks Jon. Actually I tried “x86_64-linux”, but it makes the test “Unsupported” from my linux machine, and it was because my test is under

Although this has been discussed in the past, I think that given a few conversations, it seems that it unfortunately needs to be brought up again. There seems to be some disagreement over the ideal location of the unwinder (libunwind). Currently, libunwind resides in a subdirectory of libc++abi. There seems to be some desire from multiple parties that it be moved into compiler-rt or a separate

Thanks Jon. Actually I tried “x86_64-linux”, but it makes the test “Unsupported” from my linux machine, and it was because my test is under clang, not llvm. It seems that clang doesn’t support “x86_64-linux” yet. Thanks again! Best, Taewook On 3/3/17, 10:57 AM, "Jonathan Roelofs" <jonathan at codesourcery.com> wrote: On 3/3/17 11:46 AM, Taewook Oh via llvm-dev

The source is cloned from https://github.com/llvm-mirror/llvm Thanks. Zhoulai On Thu, Apr 9, 2015 at 9:15 AM, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > > > On 4/9/15 9:58 AM, Zhoulai wrote: > >> Hi, I am using LLVM to develop a tool, using Mac OS 10.9. I have >> download llvm source and binary from >> >>

[+llvmdev, -llvm-dev] (Oopsies, llvmdev doesn't have a hyphen in it like all the others do) On 6/17/14, 10:45 AM, Jonathan Roelofs wrote: > [+llvm-dev, cfe-dev] > > Was "Re: [PATCH] ARM: allow inline atomics on Cortex M" > > On 6/17/14, 10:42 AM, Jonathan Roelofs wrote: >> >> >> On 6/17/14, 9:35 AM, Renato Golin wrote: >>> On 17 June 2014

I thought the ARM EHABI added a twist to this because it created some upward dependency from the unwinder to libc++abi. Other than that, I don’t have any strong feeling where it lives. -Nick On Jan 30, 2015, at 12:33 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 30 January 2015 at 20:17, Saleem Abdulrasool <compnerd at compnerd.org> wrote: >> There is a valid

On 7/1/14, 12:28 PM, Alp Toker wrote: > Specifically the problem I've been seeing is that people using the website are > unable to CC mailing list-based developers. As a result I don't get copied in on > responses to my review comments, and rarely get any kind of direct mail with > threading. You end up having to dig up historic responses in the mailing list > archive which

I don't see a way to create a ConstantDataVector from Constant or form APFloat though. Did I oversee that? Is the solution to had a new get function in ConstantDataVector to allow that? Any hint on what would be the right fix otherwise? Thomas -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednesday, January 14, 2015 10:30 AM To: Raoux, Thomas

>-----Original Message----- >From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >Sanjoy Das via llvm-dev >Sent: Thursday, December 03, 2015 11:16 PM >To: Quentin Colombet <qcolombet at apple.com> >Cc: llvm-dev at lists.llvm.org >Subject: Re: [llvm-dev] analyzePhysReg question > >I think this is related to PR25033:

On Thu, Apr 17, 2014 at 8:37 PM, Jonathan Roelofs <jonathan at codesourcery.com > wrote: > How about per-thread if the counter is hot enough? > Err. How do you know if the counter is hot w/o first profiling the app? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Eric, Attached are patches for llvm and clang that implement this. I've made 'none' a component that must be added explicitly (i.e. don't turn arm-eabi into arm--none-eabi, but rather turn it into arm--unknown-eabi) to try to reduce surprises. It also keeps the normalization logic a bit simpler than it would otherwise have to be. SPIR triples were one place where I was

Thanks Dan and Jon. I made an incorrect assumption that the "use" iterator was actually giving me the "user" when de-referencing it. Did it always have this behavior in previous LLVM versions? I've seen lots of examples of the "use" iterator being dereferenced and resulting Instruction pointer being treated as the "user"? Thanks, Zack On Tue, Jun 9,

Jon, > You want: > TaintVar->insertAfter(FirstI); This worked! Thank you. On Thu, Aug 25, 2016 at 9:38 AM, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > > > On 8/25/16 7:01 AM, Shehbaz Jaffer via llvm-dev wrote: >> >> I tried an alternative way of adding instruction by first getting the >> first instruction of the basic block, and then

Ø It would be good to check that this maps correctly onto computeRegisterLiveness: there's a bug in analyzePhysReg and I think other parts of the code base are slightly wrong or will become slightly wrong as well :-( Yes, I agree. I will also have to look into all other users of analyzePhysReg as well. There are surprisingly few users of either computeRegisterLiveness or analyzePhysReg.