similar to: Open Projects - Code Generator Improvements #2

I'll be attending the hacking session with the intent of understanding what needs to be done to improve ARMv5 Thumb support. With any amount of luck, we can start pounding away at the support. My initial understanding from the release notes are that http://llvm.org/bugs/show_bug.cgi?id=1388 has to be fixed first. Evan Cheng writes this in 2007: The proper fix is to model CC as explicit

Hi Joe, Not sure yet if I'll be able to make the hacking session or not, but either way, feel free to look me up at any time during the conference and I'd be happy to talk about the arm backend. Jim On Nov 16, 2011, at 7:24 AM, Joe Abbey <jabbey at arxan.com> wrote: > I'll be attending the hacking session with the intent of understanding what needs to be done to improve

> On Dec 10, 2015, at 10:49 AM, Derek Schuff <dschuff at google.com> wrote: > > > > On Thu, Dec 10, 2015 at 10:13 AM Quentin Colombet <qcolombet at apple.com <mailto:qcolombet at apple.com>> wrote: > > I am tempted to think no, we don’t, but I don’t know the use cases. > What post-RA passes with want to run with virtual regs? > > The immediate

Hello, I have come across an unusual behavior where instruction domination rule is violated "Instruction does not dominate all its uses." It concerns with StackColoring pass present at llvm/lib/CodeGen/StackColoring.cpp. I am reaching out to the LLVM community to help me understand the cause of this issue and the working of the pass. The IR produced at the end of the pass seems to be

Hi, Can anyone help me with the stack slot coloring optimization? This corresponding file is /lib/codegen/stackslotcoloring.cpp. It is said this optimization was for stack slot overlay for frame size reduction, after register allocation phase. And this transformation pass relies on the LiveStack analysis pass. How, when checking the source code, it seems the LiveStack analysis has not been

*Vivek Pandya* On Tue, Mar 1, 2016 at 10:23 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi Vivek, > > (Mostly responding with AArch64 hints, though anything I happen to > know from elsewhere too). > > On 29 February 2016 at 13:00, vivek pandya via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 2.

Hal's advice helps me a lot to understand the implementation much better. Thanks so much! So, now I am able to state my problem more clearly: 1) There are two kinds of locals, i.e., the local variables originated from the source code (like C/C++), and the compilation generated temporaries. After instruction selection phase, the former is seen as frame indexes, while the latter is seen as

2017-03-31 13:46 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > > > On Fri, Mar 31, 2017 at 4:05 AM, Michael Kruse <llvmdev at meinersbur.de> > wrote: >> >> 2017-03-31 1:16 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: >> > if you transformed >> > >> > lifetime.start(%p) >> > use %p >> >

Hey guys, I'm working on a bug for x86-64 in LLVM 2.9. Well, it's actually two issues. The assembly generated for large stack offsets has an overflow; And, once the overflow is fixed, the displacement is too large for GNU ld to handle it. void fool( int long n ) { double w[268435600]; double z[268435600]; unsigned long i; for ( i = 0; i < n; i++ ) { w[i] = 1.0; z[i] =

Hi from what I have figured out, the pass "TailCallElim" is being done in what I would call the "opt" phase of optimization. The "StackColoring" is being done in the "llc" phase. opt -> llc, so TailCallElim is always ahead. Now I would like to add something (my reusealloca idea) in "StackColoring" to get rid of some allocas, which inhibit

Hello LLVM Community, I am interested doing following project with LLVM for GSoC 2016. Code Generation Improvements: Particularly Generalize target-specific backend passes that could be target-independent I have done some initial study and try to understand the task to be done. Please help me to develop the proposal. Following are my initial findings : 1. lib/Target/Hexagon/RDF* : Code

Hi Vivek, (Mostly responding with AArch64 hints, though anything I happen to know from elsewhere too). On 29 February 2016 at 13:00, vivek pandya via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 2. lib/Target/AArch64/AArch64AddressTypePromotion.cpp > As far as I understand this pass promotes sign exertion for 32 bit integer ( > address) and performs calculation on 64 bit number

2017-03-31 1:16 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>: > if you transformed > > lifetime.start(%p) > use %p > lifetime.end(%p) > into > > if (c) > lifetime.start(%p) > use %p > lifetime.end(%p) > > That is *definitely* a bug in polly. > Stack coloring should be able to handle it if that is the original IR but that is definitely not a

The following code snippet taken from StackColoring::remapInstructions clears a mem operand if it can't guarantee whether the memoperand's underlying value aliases with the merged allocas: // Update the MachineMemOperand to use the new alloca. 522 for (MachineInstr::mmo_iterator MM = I->memoperands_begin(), .... // Climb up and find the original alloca. 532 V =

This is the email I sent last week. ---------- Forwarded message ---------- From: Akira Hatanaka <ahatanak at gmail.com> Date: Wed, May 8, 2013 at 7:04 PM Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands. To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> The following code snippet taken from StackColoring::remapInstructions clears a mem

We had some additional discussion on this. There is a lot of concern generally about post-RA passes which do not expect to have to handle virtual registers; specifically if they unexpectedly start seeing virtual registers, or if they work today but start making assumptions in the future. We discussed considering a mechanism that would require MachineFunctionPasses to "opt-in" and declare

Here are 2 patches, which are independent of each other. The first splits PrologEpilogInserter into 2 parts : http://reviews.llvm.org/D16481 After looking at the code I thought it made more sense for the major split to include whether callee-saved register spills are supported. So for non-virtual targets, virtual registers are not supported and scavenging is optionally supported, and vice versa

The patch LGTM. The StackColoring patch is still too conservative and I am consulting with Jakob and Andy about possible solutions. On May 13, 2013, at 10:33 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > This is the email I sent last week. > > ---------- Forwarded message ---------- > From: Akira Hatanaka <ahatanak at gmail.com> > Date: Wed, May 8, 2013 at 7:04

> On Dec 10, 2015, at 9:39 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > > > ----- Original Message ----- >> From: "Quentin Colombet" <qcolombet at apple.com> >> To: "Derek Schuff" <dschuff at google.com> >> Cc: "Hal Finkel" <hfinkel at anl.gov>, llvm-dev at lists.llvm.org >> Sent: Wednesday, December

Hi, I run into a a strange error when compiling with debug infos, where LLC tries to generate a variable DIE using a completely wrong frame-index (DebugDwarf tries to resolve frame index 27 in a simple function which only has a single frame object .. ). After digging around, I found that MachineModuleInfo has a VariableDbgInfo map, that is filled by SelectionDAGBuilder.