similar to: [LLVMdev] Single Exit Loops

Ralf, Ok, thanks, I'll have a look. The paper I was referencing was http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.94.668 from '90 I believe. There is also an Intel paper the expands on this for the Itanium. On Fri, Jan 6, 2012 at 12:34 PM, Ralf Karrenberg < karrenberg at cdl.uni-saarland.de> wrote: > Hi, > > I am not sure if I know the paper you mentioned, but

It looks like this problem only exists on nested loops, ideas? On Thu, Jan 12, 2012 at 11:44 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Is it not a good idea to try and extract loops that have multiple exits? > > > On Thu, Jan 12, 2012 at 10:44 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> I am trying to use ExtractLoop() but I am getting segFaults:

How do you expect people to be able to tell you if you are using it properly if they can't see how you are using it? Cameron On Jan 12, 2012, at 12:22 PM, Ryan Taylor wrote: > I'm not sure it's a bug. If I don't know if I am properly using it then how would I know it's a bug and not simply a user issue? If it sounds like a bug to you then I will file it. :) > > On

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Thu, Jan 12, 2012 at 12:22 PM Subject: Re: [LLVMdev] Extract Loop Failing To: Cameron Zwarich <zwarich at apple.com> I'm not sure it's a bug. If I don't know if I am properly using it then how would I know it's a bug and not simply a user issue? If it sounds like a bug to you then

Is it not a good idea to try and extract loops that have multiple exits? On Thu, Jan 12, 2012 at 10:44 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I am trying to use ExtractLoop() but I am getting segFaults: > > 0 opt 0x00000000008edc2f > 1 opt 0x00000000008edfda > 2 libpthread.so.0 0x00007ffe21203c60 > 3 opt 0x0000000000895ed9

I am trying to use ExtractLoop() but I am getting segFaults: 0 opt 0x00000000008edc2f 1 opt 0x00000000008edfda 2 libpthread.so.0 0x00007ffe21203c60 3 opt 0x0000000000895ed9 llvm::Value::getName() const + 9 4 LLVMEXITCDFG.so 0x00007ffe202b80d7 5 opt 0x00000000006fc6e7 llvm::LPPassManager::runOnFunction(llvm::Function&) + 1143 6 opt

Or is it in the docs such that when you use the word "independent", you really mean "independent of a particular target" and not actually "target independent"? On Thu, Dec 8, 2011 at 11:18 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > ---------- Forwarded message ---------- > From: Ryan Taylor <ryta1203 at gmail.com> > Date: Thu,

After some thought, to put this more simply (more direct), it would be fine if the getelementptr is lowered into IR assuming an x86 architecture. The real problem is that I don't want the x86 code generation, I still want to deal in LLVM IR just with the GEP lowered, and it lowered for the x86 architecture is fine. Is there any way to do this? On Thu, Dec 8, 2011 at 11:39 AM, Ryan Taylor

---------- Forwarded message ---------- From: Ryan Taylor <ryta1203 at gmail.com> Date: Thu, Dec 8, 2011 at 11:13 AM Subject: Re: [LLVMdev] GetElementPtr To: Reid Kleckner <reid.kleckner at gmail.com> There is no support for gep, it's my understanding that it's target-independent, so there's no reason to put the lowering in the target lowering portion is there?

Ok, I have attached the bugpoint-reduced-blocks.ll test case, just fyi. Thanks, I'm just curious at this point. On Wed, Feb 8, 2012 at 11:56 AM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Wed, Feb 8, 2012 at 10:09 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Unfortunately, I cannot provide the exact code, but I will attempt to > look > > for the

Do you think I could use the SelectionDAGBuilder in a pass to accomplish this for me? if there is already code that does this I don't really think I should have to do this again, unless it's not possible to access that code from the stage where I want to use it? On Thu, Dec 8, 2011 at 12:56 AM, Pedro Ferreira <pedro.ferreira at imgtec.com>wrote: > I was unaware of its removal.

Unfortunately, I cannot provide the exact code, but I will attempt to look for the reason and post a test case. On Tue, Feb 7, 2012 at 6:04 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Tue, Feb 7, 2012 at 5:52 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > opt: > /home/ryan/llvm/llvm_core/llvm-3.0/include/llvm/Support/Casting.h:194: > > typename

You're creating a new path that doesn't include L. For all values defined in L and used outside of L, you need to determine the new reaching def. That's specific to your transformation and can't be automated. Once you do that, creating the phi in F is natural. -Andy On Feb 6, 2012, at 11:51 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I guess not since Value is a

On Wed, Feb 8, 2012 at 10:09 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Unfortunately, I cannot provide the exact code, but I will attempt to look > for the reason and post a test case. Okay... note that bugpoint is very good at reducing testcases which crash. -Eli > > > On Tue, Feb 7, 2012 at 6:04 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >>

> On Aug 22, 2015, at 9:10 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > One last question regarding this please. > > Why aren't we simply changing the register class in AddRegisterOperand instead of building a new COPY? I admit I haven't thought this out but for my test cases so far this works just fine and reduces the number of ASM mov instructions that are

Does a transform exist to breakdown the GEP? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111206/e88dddfe/attachment.html>

Yes, you're probably right about the ID. The odd part is that I have other simpler instructions that use the same type of superset and it always, so far, matches correctly (it doesn't just pick GPRRegs all the time). Like I said, we can just 'fill in the gaps' with new MIs but that sure seems like a brush off solution. The td files would be so much cleaner if you could have a

> On Aug 24, 2015, at 1:30 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I'm trying to do something like this: > > // Dst = NewVReg's reg class > // *II = MCInstrDesc > // IIOpNum = II Operand Num > > if (TRI->getCommonSubClass(DstRC, TRI->getRegClass(II->OpInfo[IIOpNum].RegClass)) == DstRC) > MRI->setRegClass(VReg, DstRC); >

It seems the problem arises from using multiple reg classes for one MI in the td file, I guess. I'm not sure it takes first available, if I swap the reg classes in the list it does not change and if I replace the GPR reg class with something different than it picks the base reg class fine, potentially it is using the reg class with most available? idk. I just need to create MIs for every

Quentin, This is the issue. Somewhere prior to the constrainRegClass, it's assigning the GPRBase sub class of GPR to the MOV instruction, so it can't constrain it to Base and hence has to add the COPY. Now I just need to find out why it is ignoring the TableGen defined GPRBase for the MOV MI in favor of it's sub class GPR. Thanks. On Mon, Aug 24, 2015 at 8:34 PM, Ryan Taylor