similar to: Instruction Scheduler Code Owner: nominating Matthias Braun

I’d like to nominate Quentin Colombet as LSR code owner. He has handled most of the reviews for me for the past couple years (thanks Quentin), and is willing to take on the responsiblity. Frankly, turning over ownership to Quentin is overdue. -Andy

Hi all, I’d like to nominate Tim Northover to take over code ownership of ARM target. Thanks, Evan

On Oct 8, 2013, at 2:06 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the

Currently it will always spill / restore the whole vreg but only spilling the parts that are actually live would be a nice addition in the future. Looking at r192119': if "mtlo" writes to $LO and sets $HI to an unpredictable value, then it should just have an additional (dead) def operand for $hi, shouldn't it? Greetings Matthias Am 10/8/13, 11:03 AM, schrieb Akira

Right Matthias, I am aware that an implementation for storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these functions receive the physical register that need to be spilled, they might receive the sub-register. In this case, using the super-register naively is unsafe (e.g., one might overwrite parts of it). Thus, I think the register allocator/spillar need to be aware of the

> On Nov 17, 2016, at 8:51 PM, Andrew Trick via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I’d like to nominate Quentin Colombet as LSR code owner. He has handled most of the reviews for me for the past couple years (thanks Quentin), and is willing to take on the responsiblity. Frankly, turning over ownership to Quentin is overdue. This also seems pretty obvious to me, and

Hello. I've managed to patch the various files from the back end related to lanemask - now I have 1024-bit long lanemask. But now I get the following error when giving make llc: <<error:unhandled vector type width in intrinsic!>> This error comes from this file https://github.com/llvm-mirror/llvm/blob/master/utils/TableGen/IntrinsicEmitter.cpp, comes from the

> On Jun 27, 2017, at 2:44 PM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 6/27/2017 4:35 PM, Quentin Colombet via llvm-dev wrote: >> Yeah I was reading this as “only the non-touched part are dead”, and that’s what I’d like to see in the representation longer. Obviously, the register is not dead as a whole here :) > > I think that having

What I didn't mention in r192119 is that mthi/lo clobbers the other sub-register only if the contents of hi and lo are produced by mult or other arithmetic instructions (div, madd, etc.) It doesn't have this side-effect if it is produced by another mthi/lo. So I don't think making mthi/lo clobber the other half would work. For example, this is an illegal sequence of instructions,

To make my point clear, I believe an implementation of storeRegToStackSlot()/loadRegFromStackSlot() is not sufficient (as it received the physical register already). Does this make sense? On 2018-01-30 13:33, ahmede wrote: > Right Matthias, I am aware that an implementation for > storeRegToStackSlot()/loadRegFromStackSlot() is necessary. But these > functions receive the physical

Hi Quentin, Let me clarify if I understood this correctly. If the accesses (writes and reads) to sub-registers are expressed always as sub-registers of the super-register register class (e.g., SuperReg.sub1;), then the spilling decision is for the super register. But, if the accesses are in terms of the register class of the sub-registers directly (SubReg;), then the spilling decision will

As I've left Sony, I should handoff code ownership of the PS4 triple. Sony is still committed to LLVM and I look forward to continue to work with them in open source. Sony has asked that I nominate Paul Robinson to become code owner. +------------------------------------------------------------+ | Alexander M. Rosenberg <mailto:alexr at leftfield.org> | | Nobody cares what I

Not sure if I could follow everything in this discussion regarding subregisters. But I think the problem posted by Mikael just happened to involve subregisters, and the discussions about subregisters is confusing when it comes to Mikaels original question/problem. I think that the bundle could look something like this just as well: BUNDLE %vreg1<def,dead> * %vreg1<def> =

On 10/11/2016 at 4:15 PM, Matthias Braun wrote: > I don't find it surprising that some applications do not work properly with -ffast-math and I think we > have to accept that fact. I think it is valid to skip those tests in the test-suite when a fast math > flag combination is used (after making sure there is no easy way to make the test more robust). > I would add a

Hi Matthias, No. I want the register allocator to spill the super-register (the large one e.g., 64-bit) and not just the sub-register (e.g., the 32-bit that is a piece of of the 64-bit register) because the stack loads/store width is 64-bit in this example. RegClass1 (sub-registers): sub_registers (32-bit) --> can be natively used in arithmetic operations but no stack

> On Jun 28, 2017, at 5:10 PM, Quentin Colombet via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Oh wait, vreg1 is indeed used. > Yeah, having a dead flag here sounds wrong. I mean on the instruction itself. On the bundle, that’s debatable. That would fit the semantic “if no side effect you can kill it” (here there is side effect, we define other vregs). > >> On

Hello all, I’m planning to transition the code ownership of the Hexagon backend to Krzysztof Parzyszek. Krzysztof has done an excellent job of updating the Hexagon backend and engaging in community discussions (on the Hexagon backend and on other topics). He has a number of improvements planned for the Hexagon compiler and is an obvious choice for owning the Hexagon target. If there are no

I've been working on patches to improve subregister liveness tracking on llvm and I wanted to inform the llvm community about the overal design/motivation for them. I will send the patches to llvm-commits later today. Greetings Matthias Braun Subregisters in llvm ==================== Some targets can access registers in different ways resulting in wider or narrower accesses. For

Ok, just to clarify, RegUnits, as far I understand, are Physical registers or alias to Physical registers. They exist because some instructions use physical registers directly rather than virtual register. It's right? And why this RegUnits should be present in the Interference Graph? I thought were only the Live Intervals would be the nodes of the graph. Sorry about the trouble to

Have you seen the prototype for googlebenchmark integration I did in the past: https://reviews.llvm.org/D18428 <https://reviews.llvm.org/D18428> (though probably out of date for todays test-suite) +1 for copying the googlebechmark into the test-suite. However I do not think this should simply go into MultiSource: We currently have a number of additional plugins in the lit test runner such