similar to: [LLVMdev] new warnings

Thanks. Can you file bugzilla reports? I'll look at the first one soon. Evan On Feb 5, 2009, at 8:08 AM, Roman Levenstein wrote: > Hi, > > While testing my new register allocators on some test-cases, I've > noticed that LLVM misses sometimes some optimization opportunities: > > 1) LocalSpiller::RewriteMBB seems not to propagate the information > about e.g. Spills

Dear LLVMers, I am trying to fold memory operands in the way that is done in RegAllocLocal.cpp, or in LiveIntervalAnalysis.cpp, but I am getting errors that I don't know how to fix. Could someone tell me which steps should I take in order to correctly fold memory operands? The code that I am using is: const TargetMachine & target_machine = this->machine_function->getTarget();

Hi, While testing my new register allocators on some test-cases, I've noticed that LLVM misses sometimes some optimization opportunities: 1) LocalSpiller::RewriteMBB seems not to propagate the information about e.g. Spills between MBBs.In many cases, where MBB B1 has only one predecessor MBB B2, B1 could reuse the information about the physical registers that are in the live-out set of B2.

Hi all, I find clang-mips doesn't support constraint 'R' and I'm trying make LLVM/Clang support it. I did a little job, but Clang can not generate right code, it use the same register in inline asm, and the binary will segment fault in MIPS environment. My test case: /* constraint.c */ #include <stdio.h> int main(int argc, char* argv[]) { int a = 4; int b = 10;

On Sep 3, 2008, at 5:58 AM, Lang Hames wrote: > Hi LLVMers, > > I have finally sorted out licensing issues and found some time, so I'm > trying to port my PBQP register allocator to 2.4 in order to Nice! We would definitely welcome your contribution. > > contribute it (if you want it). I've run into a bug that has me > confused though. > > I'm currently

Hi LLVMers, I have finally sorted out licensing issues and found some time, so I'm trying to port my PBQP register allocator to 2.4 in order to contribute it (if you want it). I've run into a bug that has me confused though. I'm currently failing the following assertion: llc: VirtRegMap.cpp:1733: void<unnamed>::LocalSpiller::RewriteMBB(llvm::MachineBasicBlock&,

Ok, I've been tracking down a remat bug for over a week. I think I finally understand what is going on. This happens in specfp2006 leslie3d compiled with our frontend and optimizer. Unfortunately, getting a testcase is going to be impossible due to restrictions on SPEC redistribution and the complexity of the sequence of events leading to the bug. The bug is extremely subtle and nasty.

Hi all, The attachment supersedes the previous patch. It incorporates some feedback from Anton and takes the next step of merging the largely duplicated calling convention logic in X86ISelLowering. LowerCCCArguments, LowerX86_64CCCArguments and LowerFastCCArguments are merged and inlined directly into LowerFORMAL_ARGUMENTS. I moved LowerFORMAL_ARGUMENTS to the location where

On 2008-01-01, at 20:05, Gordon Henriksen wrote: > The attachment supersedes the previous patch. It incorporates some > feedback from Anton and takes the next step of merging the largely > duplicated calling convention logic in X86ISelLowering. > > • LowerCCCArguments, LowerX86_64CCCArguments and > LowerFastCCArguments are merged and inlined directly into >

Ok, this is a rather complicated e-mail. Please ask questions if you don't understand something. I've come across an interesting problem. I'm merging our graph coloring allocator with the code from trunk as of late last week. I have a code where a LiveInterval is spilled and some uses can be rematerialized. %reg1235 is spilled and at least one use is rematted. The remat def

> > The problem is with libgcc2, which contains libcalls needed to support > some operations > your processor cant directly do. > Yes, I mix up libgcc2 with libcpp... I have advanced a little, commenting out the fp functions. Now, it stucks at unwind-dw2.c. MipsISelLowering.cpp gives the error: Unsupported calling convention. By the way, I understand that these functions are

On 04/01/2013 12:31 PM, Chandler Carruth wrote: > On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com > <mailto:nrotem at apple.com>> wrote: > > IMHO the right way to handle target function attributes is to > re-initialize the target machine and TTI for every function (if > the attributes changed). Do you have another solution in mind ?

What is the difference between these two functions? The header file for TargetLowering class says that LowerArguments must be implemented, but only the Sparc and IA64 backends implement them. X86, PowerPC and CellSPU implement LowerFORMAL_ARGUMENTS, but I can find a setOperationAction that states that they should be lowered. Can someone please explain this for me? Thanks, Micah Villmow

Hi all, There's been a recent bootstrap failure that might be covered up because of another failure. I just wanted to point this out so that people can take a look: -bw Here's the failure from our buildbot: Assertion failed: (DestReg == VirtReg && "Unknown load situation!"), function RewriteMBB, file /Volumes/Sandbox/Buildbot/llvm/build.llvm-

Currently, Alpha, PowerPC and X86 implement LowerFORMAL_ARGUMENTS. PowerPC and X86 lower ISD::CALL in LowerOperation. Alpha implements custom select. What is the preferred way to implement this? Thanks, Rafael

Hi Andrea    Thank you your replying.    I do like your letter. Add following to line to MipsISelLowering.cpp. As your words,   @llvm.convert.to.fp16  can compile successfully. However, the runtime is not right. +  setOperationAction(ISD::FP16_TO_FP32, MVT::f32, Expand);+  setOperationAction(ISD::FP32_TO_FP16, MVT::i32, Expand); Robin yalong at multicorewareinc.com  From: Andrea Di

On Friday 09 May 2008 13:20, David Greene wrote: > One is that %reg1461 is assigned a register but LocalSpiller still tries to > remat it instead of just using the register it was assigned to. I think > it's easy enough to fix this problem, but I don't think this gets at the > deeper issue. Duh. Of course this isn't a problem. We have to remat (or load) this because

On Monday 13 July 2009 15:58, David Greene wrote: > Again, after answering the FI stack slot question, the IR-level instruction > information is the only thing we can't do through asmprinter. I'm open to > other ways of capturing the information that don't require comments in > MachineInstrs. But the information has to be stored somewhere. Ugh. I just found another

> -----Original Message----- > From: Renato Golin [mailto:renato.golin at linaro.org] > Sent: 15 May 2015 12:51 > To: Daniel Sanders > Cc: Tom Stellard; llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu > Subject: Re: [LLVMdev] 3.6.1 -rc1 has been tagged. Testing begins. > > On 14 May 2015 at 21:39, Daniel Sanders <Daniel.Sanders at imgtec.com> > wrote: > >

I don't have a target in front of me to run these tests at the moment, but walking manually through va-arg-1.c, it's pretty clear that there's some disconnect between the register spilling that happens in LowerFORMAL_ARGUMENTS and what happens in LowerVASTART in ARMISelLowering.cpp. deep On Thu, Jun 11, 2009 at 8:45 AM, robert muth<robert at muth.org> wrote: > I wrote a few