similar to: [LLVMdev] ConstantMerge & addressSpaces

On Tue, Oct 19, 2010 at 12:19 AM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com> wrote: >> But if the usage was in a loop it would be better (at the cost of >> register pressure) to materialise 5 into a register outside of the >> loop and use the register repeatedly in the loop. > > Bouncing on this subject: you can not know before isel is

Hi Arnaud, That sounds great. I look forward to seeing a patch. You may also look forward to big performance improvements in the PBQP allocator: I'm working on updates which will improve compile speeds and massively reduce memory use. Regards, Lang. On Tue, Jun 7, 2011 at 7:02 PM, Arnaud Allard de Grandmaison < Arnaud.AllardDeGrandMaison at dibcom.com> wrote: > > I also

I also considered this approach, but did not want to dive in the constraint handling for now. The PBQP path seemed easier at first sight --- and was easy to setup. And I always wanted to give a try to the pbqp :) I will add the hook to the pbqp and propose a patch if this looks clean enough. Thanks, -- Arnaud de Grandmaison -----Original Message----- From: Jakob Stoklund Olesen

Ooops, you are right. Just forgot to CC the mailing list. Thanks for noticing it,, -- Arnaud de Grandmaison ________________________________________ From: Damien Vincent [damien.llvm at gmail.com] Sent: Saturday, February 12, 2011 3:57 AM To: Arnaud Allard de Grandmaison Subject: Re: [LLVMdev] Hazard recognizers & basic blocks Merci ! I was also planning to add a second pass to verify these

On Sun, Mar 13, 2011 at 5:01 PM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com> wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64,

Thanks Eli, After digging thru mail archives & bugzilla, it seems fixing properly this issue would require a major change in the selectionDAG code --- to have it operate on a per function basis instead of per basic-block. This however, does not seem to be the only issue. The following C code does not produce an efficicient assembly sequence either. extern void f(unsigned long long v); void

I am working on a target which has some structural hazards. To detect these hazards, I implemented a sub-class of PostRAHazardRecognizer. PostRAHazardRecognizer resets the hazard state on a basic block basis. So, how to detect hazards that may occur between the end of a basic block and the beginning of another basic block ? Thanks ! -------------- next part -------------- An HTML

On 07/09/12 18:13, Chris Lattner wrote: > On Sep 7, 2012, at 8:02 AM, Richard Osborne <richard at xmos.com> wrote: >>>> I was a bit surprised to see these numbers hardcoded in TargetData since everything else is taken from the datalayout string. I was wondering what the logic was behind the number 16. Would it make sense to derive this number from the other alignments somehow

On Wed, Oct 15, 2008 at 8:28 AM, Chris Lattner <clattner at apple.com> wrote: >> I do think however that it's bit dangerous to combine static constants >> across compilation units. > > GCC does the same things with strings in some cases. You shouldn't > depend on this behavior if you want portable code. Combining is explicitly allowed for strings in C:

Hi Dan, >Did the code in the tutorial work at some point? Offhand, I wouldn't expect >any of my recent changes to have affected this. I'm reluctant to fix this >without understanding how the original code was intended to work. The code works, but not as shown in the tutorial. In the tutorial, it shows that multiple calls to pure functions (sin, cos) can be optimized. Without the

Attached is a small patch to allow users of the PBQP allocator to optionally insert a custom pass. I believe it can be usefull to other users of the pbqp. I used it to undo some of the coalescer work, and make sure that I have different virtual registers, inserting a copy if necessary, to build a pair. I noticed an unexpected --- to me at least --- behaviour of the allocator. I have some

Rob, I can reproduce the behaviour you observe using llvm top-of-tree. I will try to look into it. Best regards, -- Arnaud de Grandmaison -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rob Pieke Sent: Monday, November 15, 2010 4:27 PM To: Duncan Sands; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Optimization of calls to

Hi all, The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one for several embedded targets, with very few native types. I attached a patch to

Hi, Here is a little patch to have cmake detect dotty, and if this was the case, update the HAVE_DOTTY and LLVM_PATH_DOTTY defines in include/llvm/Config/config.h. This should apply cleanly on TOT. Best regards, -- Arnaud de Grandmaison -------------- next part -------------- An HTML attachment was scrubbed... URL:

> But if the usage was in a loop it would be better (at the cost of > register pressure) to materialise 5 into a register outside of the > loop and use the register repeatedly in the loop. Bouncing on this subject: you can not know before isel is over if the constants have to materialize into registers or not, as this is really dependent on the target's instruction set. Do we have

> let me say that in general doing this is pointless. Due to SSA form, > if %x is > set to 5 you can't set it to something else later. Thus everywhere > that you > use %x you might as well just directly use 5 there instead. But the cost of doing that might be greater than the costs of keeping it in a register. Suppose the code was ORing a value with 5 and the target only had

Hi, 1. This instruction is not selected automatically by the instruction selector. The instruction combine / select stages insert registercopies, and they are expanded later on by the copyRegToReg() function provided by the MSP430InstrInfo to this MOV16rr. 2. ReMaterializable means there is no need to find a way to preserve the value in a register : the instruction can be just be reissued

On Oct 15, 2008, at 6:58 AM, Tatu Vaajalahti wrote: >> Yes, but why do you think they should get a different address? I can >> understand that it is surprising that they do, but determining >> whether >> this is legal or not requires reading the language standard. >> Hopefully >> a language lawyer can chime in and say whether this transform is >>

Hi Arnaud, I'm glad to hear that your test case is working. I however still get my wrong allocation in some non trivial cases : the > pairing constraint is not fulfilled. > > I have tried to modify the 'ensure pairable' pass (the pass undoing some > of the coalescer's work) to always insert register copies for > instructions with the pairable constraint, instead of

On 15.10.2008, at 16.43, Duncan Sands wrote: >> True, but note that it is the address of a variable that is used, not >> the value. > > Yes, but why do you think they should get a different address? I can > understand that it is surprising that they do, but determining whether > this is legal or not requires reading the language standard. > Hopefully > a language