similar to: [LLVMdev] Proposal for new Legalization framework

On Apr 24, 2013, at 5:01 PM, Dan Gohman <dan433584 at gmail.com> wrote: > In the spirit of the (long-term) intent to migrate away from the SelectionDAG framework, it is desirable to implement legalization passes as discrete passes. Attached is a patch which implements the beginning of a new type legalization pass, to help motivate discussion. This is a great discussion to have. > Is

Hi Dan, On 25 Apr 2013, at 01:01, Dan Gohman <dan433584 at gmail.com> wrote: > The main alternative approach that's been discussed is to do FastISel to a target-independent opcode set on MachineInstrs, and then do legalization and ultimately the last phase off instruction selection proper after that. The most obvious advantage of using LLVM IR for legalization is that it's

On Wed, Apr 24, 2013 at 5:26 PM, Chris Lattner <clattner at apple.com> wrote: > On Apr 24, 2013, at 5:01 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > In the spirit of the (long-term) intent to migrate away from the > SelectionDAG framework, it is desirable to implement legalization passes as > discrete passes. Attached is a patch which implements the beginning of

Hi Dan, Others have weighed in on the merits of IR vs MI legalization, I thought I'd chip in on a different area: + /// Legal roughly means there's a physical register class on the target + /// machine for a type, and there's a reasonable set of instructions + /// which operate on registers of this class and interpret their contents + /// as instances of the type. For

One question : "In the spirit of the (long-term) intent to migrate away from the SelectionDAG framework" .. is this meant in general or just in respect to legalization? On 04/24/2013 05:01 PM, Dan Gohman wrote: > In the spirit of the (long-term) intent to migrate away from the > SelectionDAG framework, it is desirable to implement legalization passes > as discrete passes.

On 26 April 2013 19:49, Tim Northover <t.p.northover at gmail.com> wrote: > > To me, the expanding of regular IR will achieve nearly the same result as > > building a lower level IR. > > Remember that we basically already have a lower level IR consisting of > basic blocks of MachineInstrs at the moment.To an extent this has > already proven itself capable of

On Nov 19, 2009, at 2:10 PM, Jon Harrop wrote: > On Thursday 19 November 2009 19:48:18 Owen Anderson wrote: >> On Nov 19, 2009, at 10:25 AM, Jon Harrop wrote: >>>> In this case, the assertion that LLVM is slow is correct: it's >>>> definitely slower than a non-optimizing compiler. >>> >>> I'm *very* surprised by this and will test it

Hi, With this email, I would like to kick-off the development for the next instruction selector that I described during the last LLVM Dev’ Meeting. For the motivations, see Jakob’s proposal (http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html <http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-August/064727.html>) and for the proposal, see the slides (Keynote:

Hi all, Over the past few months we’ve been doing work on the foundations for the next stages of GlobalISel development. In terms of changes from this time last year, the IR translator, the legalizer, and instruction selector have seen moderate to major changes. The most significant of these was the change to the legalizer API, allowing targets to use predicates to express legality, which gives

On Nov 19, 2009, at 1:04 PM, Bob Wilson wrote: >> I've tested it and LLVM is indeed 2x slower to compile, although it >> generates >> code that is 2x faster to run... >> >>> Compared to a compiler in the same category as PCC, whose pinnacle of >>> optimization is doing register allocation? I'm not surprised at all. >> >> What else

Hello all, I would like to restrain the compiler that I build on my local box from picking all but a particular set of opcodes. Is there a way to accomplish this in a straightforward way? I'm pretty sure that there is a list of opcodes to semantics mappings. In addition, is there a way to look at an associative mapping of LLVM IR to opcode, and/or vice versa? -------------- next part

On 5/3/2017 12:04 PM, Tom Stellard via llvm-dev wrote: > On 05/03/2017 11:19 AM, Nicholas Wilson wrote: >>> Right, what I was trying to say is that there are more benefits from >>> having this not be a target than there is from having it be a target. >> Please enumerate them, I have seen none posted so far . The implied “it is what all the the other backends do” w.r.t

Hi Daniel, I had a quick look at the language reference for bitcast and I have a different reading than what you were pointing out. Indeed, my take away is: "It is always a no-op cast because no bits change with this conversion." In other words, deleting all bitcast instructions should be fine. My understanding of the quote you’ve highlighted is that it tells C programmers that this

> On 2 May 2017, at 8:48 am, Tom Stellard <tstellar at redhat.com> wrote: > You would probably need to write a new tablegen backend to generate > instruction tables that would be used outside of LLVM. I think I need to write one anyway because I need to generate lots of tables other than the instruction table (there are no registers and therefore no register table), at least one

On Fri, Jun 3, 2016 at 11:53 AM, Ahmed Bougacha <ahmed.bougacha at gmail.com> wrote: > -llvmdev at cs.uiuc.edu, that list isn't in use anymore. > > On Wed, Jun 1, 2016 at 4:48 PM, Kenneth Adam Miller via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Hello all, > > > > I would like to restrain the compiler that I build on my local box from >

>Right, what I was trying to say is that there are more benefits from >having this not be a target than there is from having it be a target. Please enumerate them, I have seen none posted so far . The implied “it is what all the the other backends do” w.r.t ISel/MC is at best(worst?) an implementation detail, and I’m still not quite sure why Chandler was so adamant about that. He seemed

Hi Daniel, Thanks for the pointers, I wasn’t aware of the second thread you’ve mentioned. I may be wrong but I think LLVM-IR optimizations really treat bistcasts as no-op casts, in the sense of no instructions are required. Is there anyone that could chime in on that? However, it seems SelectionDAG sticks to the load/store semantic: "BITCAST - This operator converts between integer,

Hi, > I found this thinking quite difficult to explain. Does it make sense? It might help to link to the documentation on why bitcasts are weird on big-endian NEON: http://llvm.org/docs/BigEndianNEON.html#bitconverts Cheers, James On Tue, 12 Jan 2016 at 13:23 Daniel Sanders via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > > I haven't found much time to

Totally agree Philip! I think the main pending issue is are we allowed to have a target that doesn't go through the normal mechanisms that targets adhere to - and is basically just a ModulePass underneath. In light of how thorny this request has been perceived in the past, I'd honestly rather just make external targets work _without_ patching LLVM being a requirement, and then any

Hello all, I would like to enhance LLVM debug info that supports setting breakpoint on labels in function. Generally, if users use GDB as their debugger, they could set breakpoints on labels in function. Following is an example. // C program static int myfunction (int arg) { int i, j, r; j = 0; /* myfunction location */ r = arg; top: ++j; /* top location */ if (j == 10) goto