similar to: Reaching definitions on Machine IR post register allocation

Hi Venu, > On Sep 11, 2017, at 11:00 PM, Raghavan, Venugopal via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Krzysztof, > > Thanks for your reply. > > I agree that adding extra register units for x86 would be the right way to fix this. Do you know if there is a plan to fix this? No concrete plan, no. We've been thinking about for quite some time now, but

Hi Venu, FWIW, I have a pass that does copy propagation after RA [1] (currently only within a basic block) that should be enabled some time in the not-too-distant future. It has been reviewed and accepted, but I'm currently working on getting a slight change to the MachineOperand representation [2] that should make the copy propagation change much simpler. I believe this change to

Hi Geoff/Krzyssztof, Wouldn't the isRenamable() change be required even for the RDF based copy propagation? Maybe Hexagon does not impose ABI/ISA restrictions which require specific registers to be used in specific contexts. Also, if Geoff's copy propagation pass is invoked post-RA wouldn't it need to handle the x86 ISA feature which allows 8 bit/16 bit values to be moved into a

Hi Venu, This is happening because there is an implicit def of ECX on the COPY instruction. This was an issue on Hexagon as well. Let me give you some background. There are two kinds of implicit defs (and implicit uses, but I'll refer only to defs for brevity): (1) Those that indicate that some physical register (that is not an operand) is modified by a given instruction (EFLAGS is a good

Hi Krzysztof, In one of your earlier emails in this thread you mentioned that you had some changes which add extra aliases for subregisters. Did you mean for X86? And is it extra register units that you added or aliases? I tried adding extra register units for X86 through some changes in CodeGenRegisters.cpp in TableGen but I am seeing a runtime error in one of my test cases possibly due to the

Hi All, I was looking into MachineCopyPropagationPass.ccp file in llvm, which in first look, looks likes to me doing only redundant copy elimination in same basic block. I am interested in any pass which is doing copy propogation across the basic block in a function. Let me know if any such pass exist ? Thanks, Deepali -------------- next part -------------- An HTML attachment was scrubbed...

On 9/28/2016 2:59 PM, Quentin Colombet wrote: > The cases where that it could make sense to use unaddressable register units are: > > 2. If we want to track precise liveness for physical registers > > #2 is not a problem IMO since most of our work with liveness happens on unallocated code. This is what I'm working on (RDF). I generate a data-flow graph for physical registers,

Hi Raghavan, I concur no specific docs. What do you want to know specifically? Cheers, -Quentin > On Jul 5, 2017, at 11:16 PM, Madhur Amilkanthwar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > AFAIK, no official doc. > You can probably get better help if you ask specific questions (which part of the code you don't understand). > > On Thu, Jul 6, 2017 at 9:53

Hi, Sorry I took a long time to reply as it took me some time to get some understanding of the code even to ask some specific questions (I have a test case in which LSR does not kick in and wanted to understand the code to figure out why it was not kicking in). Here are some specific questions I have: 1) It appears that LSR works only for the inner-most loop. Is this correct? Can you tell

On 9/28/2016 1:20 PM, Quentin Colombet wrote: > >> On Sep 28, 2016, at 10:52 AM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On X86, the registers AX, EAX and RAX all share the exact same register units. In terms of units, there is no difference between these registers. This makes register units insufficient to track liveness, since live AX

Hi, My name is Venugopal Raghavan and I work in AMD. I was trying to understand the code in the file LoopStrengthReduce.cpp but I am making very slow progress. Is there any additional documentation available that would help me understand the code, like a PPT presentation or a design document or maybe a paper? I did not find anything on the Internet. There are comments interspersed in the code

Hi, I was interested in trying out LLVM BOLT and generated profile data using Linux perf using the following: perf record -e cycles:u -o perf.data <command> This is without the use of LBR so I understand the performance improvements may not be much but this was more for becoming familiar with BOLT's commands. I then run: perf2bolt -nl -p perf.data -o perf.fdata <binary> and I

On 9/28/2016 7:30 PM, Quentin Colombet wrote: > Out of curiosity, could describe why this is useful to have such precision in the liveness tracking? RDF is meant to allow optimizations across the whole function. As a result, registers may change between basic blocks, and there is code to recalculate it. Accuracy is required to avoid unnecessary block live-ins. For example, calculate live-ins

Enabling subreg liveness tracking didn't do anything. By altering the allocation order I managed to get the backend to use CL/CH for the struct, but the stores were still separate (even though storing CX would be correct)... Here's another question that falls into the same category: The function X86InstrInfo::loadRegFromStackSlot does not append any implicit uses/defs. How does it

Dear Community, I would like to discuss few points to use RDF to extend register remat scope. Mr. Krzysztof and I have started discussion this on private mail. But I think now it would be better to include community. Interested community member kindly previous discussion (at the end of mail) before starting here. After analyzing if RDF can be used for solving Remat, we think that problem with

Hi Krzysztof, > On May 24, 2016, at 8:03 AM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'm trying to see how the x86 backend deals with the relationship between AL, AH and AX, but I can't get it to generate any code that would expose an interesting scenario. > > For example, I wrote this piece: > > typedef struct { > char x,

On 5/25/2016 12:35 PM, Quentin Colombet wrote: > > Doing that would say that we override the other lanes of EAX, which is > not what we want. In what cases, do we need to add those implicit arguments? If you had AL<def> = ... AH<def> = ... ... = AX you'd need implicit uses/defs to define AX. This sort of thing happens on Hexagon very often: general purpose

I'm trying to see how the x86 backend deals with the relationship between AL, AH and AX, but I can't get it to generate any code that would expose an interesting scenario. For example, I wrote this piece: typedef struct { char x, y; } struct_t; struct_t z; struct_t foo(char *p) { struct_t s; s.x = *p++; s.y = *p; z = s; s.x++; return s; } But the output at -O2

Hi, I am new to MemorySSA and wanted to understand its capabilities. Hence I wrote the following program (test.c): int N; void test(int *restrict a, int *restrict b, int *restrict c, int *restrict d, int *restrict e) { int i; for (i = 0; i < N; i = i + 5) { a[i] = b[i] + c[i]; } for (i = 0; i < N - 5; i = i + 5) { e[i] = a[i] * d[i]; } } I compiled this program using

On 3/1/2016 11:26 AM, vivek pandya via llvm-dev wrote: > > Still I am looking for feedback on RDF part and also if some one is > willing to mentor me. Hi Vivek, Sorry, I missed this email. I wrote the RDF stuff and I'd be happy to help you out with it if you are interested. The idea was to have a utility class that would represent the data flow between registers. The registers