similar to: [LLVMdev] Question about LLVM r184574

Hi Quentin and llvm-dev, I've got a regalloc-related question that you might have an opinion or answer about. In our out-of-tree target we've been doing some bundling before register allocation for quite some time now, and last night a new problem popped up. What the fix should be depends on if this bundle is legal or not: BUNDLE %vreg39<imp-def,dead> *

I will be removing RegAllocLinearScan and VirtRegRewriter from trunk shortly after we cut the 3.0 release branch. LLVM 3.0 will still ship with the linear scan register allocator, but the default will be the new greedy allocator. Linear scan can be enabled by passing '-regalloc=linearscan -join-physregs' to llc. RegAllocLinearScan and VirtRegRewriter need to go away soon because they

Hi Ryan, > On Mar 14, 2016, at 7:49 AM, Ryan Taylor via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I looked at this again and it appears that while spillAroundUses sets the register as 'dead', there is no checking to see if it's dead in subsequent iterations of the bundle loop. > > Is this intentional? > > On Mon, Mar 7, 2016 at 3:28 PM, Ryan

The isKill must be correct if present, but a vreg may still be killed even if the operand has no Kill flag. The isDead and isUndef flags however are required to be correct. We need further details to say anything about your problem, a LiveIntervals::dump() dump for example would be helpful to assess whether the liveness data is correct in your case. - Matthias > On Jul 28, 2016, at 1:42 PM,

I have a question about the performance of the implementation of the stack protector in LLVM. Consider the following C program: ===== void canary() { char buf[20]; buf[0]++; } int main() { int i; for (i = 0; i < 1000000000; ++i) canary(); return 0; } ===== This should definately run slower when stack protection is enabled, right? I have measured the runtime of

I am observing poor instruction scheduling in my out-of-tree target. The problem is an over-constrained scheduling DAG. In particular, the DAG includes spurious output dependencies on physical, non-register-allocatable registers. MISched already includes code to avoid this problem. However that code relies on information clobbered by the earlier pass LiveVariables. I wonder whether this is a

On Fri, Jun 11, 2010 at 2:55 PM, Ben Ransford <ransford at cs.umass.edu> wrote: > Yesterday I noticed that MSP430 argument passing is broken in trunk; > see http://llvm.org/PR6573 for details and testcases.  The problem is > that calls aren't being preceded by instructions that put the > arguments into registers.  I backtracked my working copy and then > stepped forward

On 7/28/2016 3:49 PM, Matthias Braun wrote: > > The isDead and isUndef flags however are required to be correct. Undef yes, but what relies on isDead being accurate (before live interval computation)? -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

> On Jul 28, 2016, at 1:52 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > > On 7/28/2016 3:49 PM, Matthias Braun wrote: >> >> The isDead and isUndef flags however are required to be correct. > > Undef yes, but what relies on isDead being accurate (before live interval computation)? I only remember Andy/Quentin making those conservative correctness

If you compile this with optimizations, then the 'canary()' function should be totally inlined into the 'main()' function. In that case, the cost of the stack protectors will be very small compared to the loop. -bw On Mar 9, 2012, at 2:52 AM, Job Noorman <jobnoorman at gmail.com> wrote: > I have a question about the performance of the implementation of the stack >

On 2011-03-09 02:51, Bill Wendling wrote: > There are LLVM 2.9 RC1 pre-release tarballs source available. You can find them here: > llvm 2.9rc1 test on Dualcore ARM running Ubuntu Natty gunzip llvm-2.9rc1.src.tar.gz tar zxvf llvm-2.9rc1.src.tar cd llvm-2.9-build ../llvm-2.9rc1/configure --enable-shared time make clean ;time make CXXFLAGS=-marm CFLAGS=-marm xranby at

When compiling trunk using gcc 4.1.2 on linux/ppc64, I now see a warning that I don't remember seeing previously: llvm[2]: Compiling InlineSpiller.cpp for Release+Asserts build /src/llvm-trunk-dev/include/llvm/ADT/PointerIntPair.h: In member function ‘const PointerTy* llvm::PointerIntPair<PointerTy, IntBits, IntType, PtrTraits>::getAddrOfPointer() const [with PointerTy = void*, unsigned

I think I'm getting a bit closer to the problem. I've found that the call to InlineSpiller::foldMemoryOperand() inside InlineSpiller::spillAroundUses() is causing the problems. As a test, I removed that call and with your yesterday's patch I'm not getting any errors at all, the code generated is the same one as with the call. This is happening when

Hi Gents, For those of us with out-of-tree backends which are not 32bit, the msp430 backend is a useful vehicle for examining changes and testing out ideas. So I was wondering about enabling debug output on the MSP430 backend so that I can illustrate a few issues to Adrian and you on the variable pieces side. (there doesn't appear to be any specific person claiming the msp430 code right

Hello, Yesterday I noticed that MSP430 argument passing is broken in trunk; see http://llvm.org/PR6573 for details and testcases. The problem is that calls aren't being preceded by instructions that put the arguments into registers. I backtracked my working copy and then stepped forward until it broke between r98937 and r98938. Refining further, I found that rolling back the

On Jul 15, 2012, at 4:50 PM, Borja Ferrer <borja.ferav at gmail.com> wrote: > I think I'm getting a bit closer to the problem. I've found that the call to InlineSpiller::foldMemoryOperand() inside InlineSpiller::spillAroundUses() is causing the problems. > As a test, I removed that call and with your yesterday's patch I'm not getting any errors at all, the code

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" >Matthias,</div> <div dir="ltr" > </div> <div dir="ltr" >Thanks for the response.</div> <div

lib/CodeGen/RegAllocLocal.cpp:38: warning: 'NumFolded' defined but not used This has been introduced because of r46821. However, maybe removing just the variable isn't enought, because the comments in the section that got modified by 46821 are not optimal: if (PhysReg) { // Register is available, allocate it! assignVirtToPhysReg(VirtReg, PhysReg); } else { // No

> On Jul 28, 2016, at 2:01 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Jul 28, 2016, at 1:52 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: >> >> On 7/28/2016 3:49 PM, Matthias Braun wrote: >>> >>> The isDead and isUndef flags however are required to be correct. >> >> Undef yes,

Hello, I have a user asking about msp430 support for Zig. When they try to target msp430, this error is triggered: if (target_machine->addPassesToEmitFile(MPM, dest, ft)) { *error_message = strdup("TargetMachine can't emit a file of this type"); return true; } I tried using clang alone: clang -c add.c -target msp430-unknown int add(int