similar to: [LLVMdev] GetElementPtr

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.

---------- 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?

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,

On Wed, Dec 7, 2011 at 1:50 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > There is a GEPSplitterPass in the Scalar.h but not in the > LLVM_SRC/lib/Transforms/Scalar folder, there is no GEPSplitterPass.cpp > file. Is it possible to get this from 2.8 and compile it and use it for 2.9? > > > On Wed, Dec 7, 2011 at 12:31 PM, Ryan Taylor <ryta1203 at gmail.com> wrote:

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

No I think I misunderstood you, I actually want the GEP broken down into it's arithmetic instructions, I don't want any GEP instructions in my code at all. Is there a way to do that? On Wed, Dec 7, 2011 at 2:24 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > > On Wed, Dec 7, 2011 at 1:50 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> There is a

Hi, It's changed a few times over the last year. I believe xdg-open spawns whichever application your desktop environment would use to open the file so you should be able to tell it to use dotty. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Ryan Taylor via llvm-dev Sent: 11 August 2015 00:30 To: llvm-dev at lists.llvm.org Subject: [llvm-dev] Fwd: [LLVMdev]

The diff is not only the && and || but also the leading !: diff --git a/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp b/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp index 58f029fbe9fc..7ee06fc153b2 100644 --- a/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp +++ b/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp @@ -659,7 +659,7 @@ void SelectionDAGISel::CodeGenAndEmitDAG() {

Daniel, Ok, thanks. Simple fix. We'll just make correction in local copy for now, one less thing to port later :) Thanks. On Mon, Jul 27, 2015 at 12:29 PM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > I've just looked at my checkout of 3.6 and it looks like the fix wasn't > merged. I don't have the revision number for the fix to hand but in >

Ok, thanks, this makes sense. But there is no way to get the SelectionDAG to do it for me via something like visitGetElementrPtr? On Thu, Dec 8, 2011 at 2:54 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > > On Thu, Dec 8, 2011 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> > >> Thanks. > >> > >> So basically then this

I've just looked at my checkout of 3.6 and it looks like the fix wasn't merged. I don't have the revision number for the fix to hand but in lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, this: MatchFilterBB = (!FilterDAGBasicBlockName.empty() && FilterDAGBasicBlockName == FuncInfo->MBB->getBasicBlock()->getName().str());

On Thu, Dec 8, 2011 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Thanks. > > So basically then this operation is not target-independent like the docs > suggest? > > > On Thu, Dec 8, 2011 at 1:23 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > >> On Thu, Dec 8, 2011 at 11:49 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: >>

On Fri, 2010-09-17 at 12:16 +0100, David Given wrote: > On 17/09/10 09:55, Pedro Ferreira wrote: > > As I understand it, LLVM simply gives you support for garbage collectors > > that you have to implement yourself and link into the final binary, > > similar to what C's malloc does (it's a library call). The issue with > > GC's is that they need to be provided

On Thu, Dec 8, 2011 at 3:29 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ok, thanks, this makes sense. But there is no way to get the SelectionDAG to > do it for me via something like visitGetElementrPtr? SelectionDAGBuilder::visitGetElementPtr uses the same algorithm you want to use, but it is specialized for building a SelectionDAG, which is lower level than LLVM IR. -Eli >

On 17/09/10 09:55, Pedro Ferreira wrote: > As I understand it, LLVM simply gives you support for garbage collectors > that you have to implement yourself and link into the final binary, > similar to what C's malloc does (it's a library call). The issue with > GC's is that they need to be provided info about the stack, thats where > LLVM's support comes in. Are there

Hello, We are linking our llvm build with other libraries and for testing purposes we use llc (bypassing our own driver). Because our backend has forward dependencies to our driver we added #defines to cut out the dependencies on our source. When we want to compile with our own driver, we compile llvm with "libs-only" and simply link the libraries. Is there a way, on the makefile of our

Daniel, We are using 3.6. Someone also pointed out that it was mandatory in 3.6.2 but I have not verified that. On Mon, Jul 27, 2015 at 12:10 PM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > It's not supposed to be. There was a short period where it was > unintentionally mandatory but this was fixed after I pointed it out during > post-commit review. > >

Eli, Ok, thanks, this is a big help. So how can I use the TargetData (or get the TargetData) without having a DAG? On Thu, Dec 8, 2011 at 3:45 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Dec 8, 2011 at 3:29 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Ok, thanks, this makes sense. But there is no way to get the > SelectionDAG to > > do it

#define r10(p,q,r,s) 0x##s##r##q##p #undef r #define r r10 const word it_tab[4][256] = { r(const, const, const, const), r(.......), r(.......) ....... }; All of this is done inside the function I want the alloc in. The variable is not declared/defined/used anywhere else. On Wed, Aug 15, 2012 at 12:00 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Wed, Aug 15, 2012

> On Thu, Dec 8, 2011 at 2:37 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> >> Thanks. >> >> So basically then this operation is not target-independent like the docs >> suggest? It is target-independent in the sense that a frontend can generate code using GEP's without worrying about how a given target actually lays out structures. It isn't