similar to: Is there any pass existing in llvm which does machine copy propogation ?

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, Just to clarify I am looking for a whole machine function analysis not just something restricted to within a machine basic block. Thanks. Regards, Venu. From: Raghavan, Venugopal Sent: Saturday, September 02, 2017 12:56 PM To: llvm-dev at lists.llvm.org Subject: Reaching definitions on Machine IR post register allocation Hi, Given a definition of a register by a machine instruction in

I have modified the example test case for UB error, still it didn’t unroll void foo(int x) { int p, i = 1; int mat[9][9][9]; for (p = (x+1) ; p < (x+3) ;p++) mat[x][p-1][i] = mat[x][p-1][i] + 5; } Regard, Deepali From: Kevin Choi [mailto:code.kchoi at gmail.com] Sent: Friday, September 16, 2016 1:20 PM To: Rai, Deepali Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] SCEV

Hi All, I am trying to unroll the below loop, but couldn't as SCEV returns TripCount as 0. void foo(int x) { int p, i = 1; int mat[6][6][6]; for (p = x+3 ; p<= x+6 ;p++) mat[x][p][i] = mat[x][p][i] + 5; } For a quick reference I have added the generated IR compiled with clang using -O3. Please let me know if this is an known issue in SCEV or I am missing something here ? ;

Hi Deepali, SCEV reports the backedge taken count as "((-1 * (sext i32 (3 + %x) to i64))<nsw> + ((sext i32 (3 + %x) to i64) smax (sext i32 (6 + %x) to i64)))", so symbolically it does have an answer. Ideally SCEV should be able to exploit <nsw> on (3 + %x) and (6 + %x) to fold the expression above to "3", but due to some systemic issues SCEV can't exploit

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

My apologies for not including the transcript in the original message: > xx <- rep(2.10,80) > groups.balanced <- as.factor(c(rep("one",40),rep("two",40))) > groups.unbalanced <- as.factor(c(rep("one",44),rep("two",36))) > t.test(xx ~ groups.balanced) Welch Two Sample t-test data: xx by groups.balanced t = 0, df = 78, p-value = 1

# users would benefit from a warning about the behavior in the # groups.unbalanced case below. A propogation of difference is the variance # calculation is leading to an apparently significant difference in # means, even though the numeric values are all identical. Obviously upon # inspection the difference in means is meaningless, but users might be warned # if all of the input data is

Hello, All services have been successfully migrated to our new facility. Unfortunately, NetSol once again displayed a brilliant inability to grasp a clue using both hands and a suction cup, and informed us they *might* get around to updating DNS records in about two weeks. If we could fax them enough identification. Needless to say, they've lost our business and our domain transfers should

Hello, All services have been successfully migrated to our new facility. Unfortunately, NetSol once again displayed a brilliant inability to grasp a clue using both hands and a suction cup, and informed us they *might* get around to updating DNS records in about two weeks. If we could fax them enough identification. Needless to say, they've lost our business and our domain transfers should

Hello, All services have been successfully migrated to our new facility. Unfortunately, NetSol once again displayed a brilliant inability to grasp a clue using both hands and a suction cup, and informed us they *might* get around to updating DNS records in about two weeks. If we could fax them enough identification. Needless to say, they've lost our business and our domain transfers should

Hello, All services have been successfully migrated to our new facility. Unfortunately, NetSol once again displayed a brilliant inability to grasp a clue using both hands and a suction cup, and informed us they *might* get around to updating DNS records in about two weeks. If we could fax them enough identification. Needless to say, they've lost our business and our domain transfers should

Hello, All services have been successfully migrated to our new facility. Unfortunately, NetSol once again displayed a brilliant inability to grasp a clue using both hands and a suction cup, and informed us they *might* get around to updating DNS records in about two weeks. If we could fax them enough identification. Needless to say, they've lost our business and our domain transfers should

Hello, All services have been successfully migrated to our new facility. Unfortunately, NetSol once again displayed a brilliant inability to grasp a clue using both hands and a suction cup, and informed us they *might* get around to updating DNS records in about two weeks. If we could fax them enough identification. Needless to say, they've lost our business and our domain transfers should

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

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

Hello all, For my custom processor backend I am trying add some instruction using BuildMI() inside eliminateFrameIndex(). I tried RegScavenger like this: unsigned RegUnused0 = RS->FindUnusedReg(&LASER::GNPRegsRegClass); if (!RegUnused0) RegUnused0 = RS->scavengeRegister(&LASER::GNPRegsRegClass, II, SPAdj); assert(RegUnused0 && "Register scavenger failed");