search for: combineloadtooperationtype

Hello, Context: We have a backend where v32i1 is a Legal type, but the storage for v32i1 is not 32-bits/uses a different instruction sequence. We ran into an issue because combineLoadToOperationType changed v32i1 loads into i32 loads, so a sequence like: define void @bits(<32 x i1>* %A, <32 x i1>* %B) { %a = load <32 x i1>, <32 x i1>* %A store <32 x i1> %a, <32 x i1>* %B ret void } Is transformed to: define void @bits(<32 x i1>* %A, <32 x i1&...

...%struct.s* %ptr1 to i64 bb2: %int2 = ptrtoint %struct.s* %ptr2 to i64 %bb3: %phi.node = phi i64 [ %int1, %bb1 ], [%int2, %bb2 ] %ptr = inttoptr i64 %phi.node to %struct.s* In short, the pattern above arises due to: 1. InstCombine introducing a bitcast while performing a canonicalization in combineLoadToOperationType() [1] 2. GVN performing "load coercion" and replacing a load with a ptrtoint (ptrtoint is due to the bitcast) 3. SROA replacing store- and load-instructions with phi nodes. The question is: is it a good idea to clean ptrtoint/inttoptr instructions inside SROA or should it be done higher...

...>> >> %bb3: >> %phi.node = phi i64 [ %int1, %bb1 ], [%int2, %bb2 ] >> %ptr = inttoptr i64 %phi.node to %struct.s* >> >> In short, the pattern above arises due to: >> 1. InstCombine introducing a bitcast while performing a canonicalization in >> combineLoadToOperationType() [1] >> 2. GVN performing "load coercion" and replacing a load with a ptrtoint >> (ptrtoint is due to the bitcast) >> 3. SROA replacing store- and load-instructions with phi nodes. >> >> The question is: is it a good idea to clean ptrtoint/inttoptr instructi...

----- Original Message ----- > From: "Bjarke Roune" <broune at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: llvmdev at cs.uiuc.edu, "Jingyue Wu" <jingyue at google.com> > Sent: Wednesday, July 1, 2015 2:27:59 PM > Subject: Re: [LLVMdev] Deriving undefined behavior from nsw/inbounds/poison for scalar evolution > >

...analysis. I also think that defining psub as instruction is fine. :) > Regarding the instcombine, it should be very easy to keep loads and stores of pointers as pointer typed in instcombine. Likely just a missing case in the code I added/touched there. That's really good. :) I found that combineLoadToOperationType from InstCombineLoadStoreAlloca was responsible for the transformation. I can upload a patch for that if ok. Best Regards, Juneyoung Lee On Mon, Jan 14, 2019 at 5:36 PM Chandler Carruth <chandlerc at gmail.com> wrote: > While I'm very interested in the end result here, I have some q...

...ction is fine. :) >> >> > Regarding the instcombine, it should be very easy to keep loads and >> stores of pointers as pointer typed in instcombine. Likely just a missing >> case in the code I added/touched there. >> >> That's really good. :) I found that combineLoadToOperationType from >> InstCombineLoadStoreAlloca was responsible for the transformation. >> I can upload a patch for that if ok. >> >> Best Regards, >> Juneyoung Lee >> >> On Mon, Jan 14, 2019 at 5:36 PM Chandler Carruth <chandlerc at gmail.com> >> wrote: &gt...

Hello all, This is a proposal for reducing # of ptrtoint/inttoptr casts which are not written by programmers but rather generated by LLVM passes. Currently the majority of ptrtoint/inttoptr casts are generated by LLVM; when compiling SPEC 2017 with LLVM r348082 (Dec 2 2018) with -O3, the output IR contains 22,771 inttoptr instructions. However, when compiling it with -O0, there are only 1048