similar to: [LLVMdev] anti-dependency breaking and mask/shift dependencies

On Jun 9, 2012, at 10:12 PM, Hal Finkel wrote: > On PowerPC (at least versions which predate the mfocrf instruction), > while there are multiple independent condition registers, the only way > to move those registers into a general-purpose register is to use mfcr, > which transfers all of the (concatenated) condition registers into one > general purpose register, followed by a

On Sun, 10 Jun 2012 09:32:45 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 9, 2012, at 10:12 PM, Hal Finkel wrote: > > > On PowerPC (at least versions which predate the mfocrf instruction), > > while there are multiple independent condition registers, the only > > way to move those registers into a general-purpose register is to > >

On Jun 11, 2012, at 8:07 AM, Hal Finkel wrote: > Also, I think the following might work well: If we add a special kind > of register dependency called a 'remembered' register. This is not a > real dependency meaning that that the instruction does not actually > read or write to the register, but it means that if the register > allocator (or anything else) swaps the

On Mon, 11 Jun 2012 08:56:21 -0700 Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > > On Jun 11, 2012, at 8:07 AM, Hal Finkel wrote: > > > Also, I think the following might work well: If we add a special > > kind of register dependency called a 'remembered' register. This is > > not a real dependency meaning that that the instruction does not >

Hello to all. I'm trying to implement a simple register allocator using graph colouring (I know, everyone has already done that :-)) and I'm also using LLVM 3.4 from master branch. The algorithm I'm using is based on the one described on the "Modern Compiler Implementation in C". My implementation is totally experimental and doesn't aim to be fast, eficient or even

Cool, that worked. New patch attached... Cheers, Gary Evan Cheng wrote: > Just cast both values to const TargetRegisterClass*. > > Evan > > On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > > Evan Cheng wrote: > > > How about? > > > > > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > > > &PPC:G8RCRegClass; >

On Sep 17, 2013, at 5:15 AM, Leandro Santiago <leandrosansilva at gmail.com> wrote: > Hello to all. I'm trying to implement a simple register allocator using graph colouring (I know, everyone has already done that :-)) and I'm also using LLVM 3.4 from master branch. > > The algorithm I'm using is based on the one described on the "Modern Compiler Implementation in

Good Night. I'm implementing a Interference Graph in the Register Allocation pass. I'm building this graph BEFORE any assignment of a virtual register to physical register. But I have a doubt about how to check the interference between two Live Intervals (i.e. They live at same point), should I use: L1->overlaps(L2) Where L1 and L2 are two different Live Intervals. Or should I use:

Ok, just to clarify, RegUnits, as far I understand, are Physical registers or alias to Physical registers. They exist because some instructions use physical registers directly rather than virtual register. It's right? And why this RegUnits should be present in the Interference Graph? I thought were only the Live Intervals would be the nodes of the graph. Sorry about the trouble to

Hello to all LLVM developers. I'm developing a register allocator using LLVM, my allocator has a local search phase: given a solution (assignment of virtual registers to physical registers or memory) generated in the first phase of the algorithm, some movements are applied to this solution in order to find a better solution. To apply such movements, I need to unassign a virtual register from

Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3 -mllvm -debug-pass=Arguments program.c -c bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias

On Wed, Sep 15, 2004 at 10:48:02AM +0930, Alan Modra wrote: > After using SHAREDFLAGS = -Ttext 0x0f000200 on ppc64 (which I see you > suggested in another email), I see the problem you're talking about. > > klibc is fundamentally broken on ppc64. You just can't call into > another chunk of code (klibc.so in this case) which has a separate toc > and expect things to

I'm working on my project for completion undergraduate courses, consisting of an experimental analysis of registers allocation algorithms. For this task, I am using the set of tools from the LLVM project. However, I have read the documentation of the LLVM project and not yet found a way to put the pieces of the puzzle together. So far I know: - As passes work as engage them to LLVM and

Is there any way to determine if a Register-type MachineOperand represents a fixed machine register? For example, call arguments must end up in specific machine register but I don't see any way to ascertain this from the information in MachineOperand. Basically, I need to know if I am allowed to rename a MachineOperand or not after register allocation. Thanks!

On May 16, 2013, at 2:23 PM, dag at cray.com wrote: > Is there any way to determine if a Register-type MachineOperand > represents a fixed machine register? For example, call arguments must > end up in specific machine register but I don't see any way to ascertain > this from the information in MachineOperand. Basically, I need to know > if I am allowed to rename a

PPCTargetLowering::EmitInstrWithCustomInserter has a reference to the current MachineFunction for other purposes. Can you use MachineFunction::getRegInfo instead? Dan On Jul 8, 2008, at 1:56 PM, Gary Benson wrote: > Would it be acceptable to change MachineInstr::getRegInfo from private > to public so I can use it from > PPCTargetLowering::EmitInstrWithCustomInserter? > >

Hi Gary, This does not patch cleanly for me (PPCISelLowering.cpp). Can you prepare a updated patch? Thanks, Evan On Jul 10, 2008, at 11:45 AM, Gary Benson wrote: > Cool, that worked. New patch attached... > > Cheers, > Gary > > Evan Cheng wrote: >> Just cast both values to const TargetRegisterClass*. >> >> Evan >> >> On Jul 10, 2008, at 7:36

Hi Evan, Evan Cheng wrote: > This does not patch cleanly for me (PPCISelLowering.cpp). Can you > prepare a updated patch? This should work, though I won't have access to my test box now until next Thursday so no guarantees :) Cheers, Gary -- http://gbenson.net/ -------------- next part -------------- Index: lib/Target/PowerPC/PPCISelLowering.h

Just cast both values to const TargetRegisterClass*. Evan On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > Evan Cheng wrote: >> How about? >> >> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : >> &PPC:G8RCRegClass; >> unsigned TmpReg = RegInfo.createVirtualRegister(RC); > > I tried something like that yesterday: > > const

Evan Cheng wrote: > How about? > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > &PPC:G8RCRegClass; > unsigned TmpReg = RegInfo.createVirtualRegister(RC); I tried something like that yesterday: const TargetRegisterClass *RC = is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass; but I kept getting this error no matter how I arranged it: