search for: topper

Hi Craig, thanks for digging into this. So InstCombine is the wrong place for fixing PR34474. Can you give me a hint where such an optimization should go into CodeGen? I am not really familiar with stuff that happens after the MidLevel. Cheers, Michael Am 13.09.2017 um 19:21 schrieb Craig Topper: > And that is less instructions. So from InstCombine's perspective the > multiply is the correct answer. I think this transformation is better > left to codegen where we know whether multiply or shift is truly better. > > ~Craig > > On Wed, Sep 13, 2017 at 10:18 AM, Cr...

...rform this in DAGCombiner and remove the various target specific combines that we still have. At least ARM/AARCH64 and X86 have cases that can hopefully be generalised and removed, but there will probably be a few legality/perf issues that will occur. Simon. > On 14 Sep 2017, at 06:23, Craig Topper <craig.topper at gmail.com> wrote: > > Probably in visitMUL in DAGCombiner.cpp to be target independent. Or in LowerMUL in X86ISelLowering.cpp to be X86 specific. > > Adding Simon. Simon, which were you thinking? > > ~Craig > > On Wed, Sep 13, 2017 at 10:06 PM, Hai...

...e the various target specific combines that we still have. > > At least ARM/AARCH64 and X86 have cases that can hopefully be > generalised and removed, but there will probably be a few legality/perf > issues that will occur. > > Simon. > >> On 14 Sep 2017, at 06:23, Craig Topper <craig.topper at gmail.com<mailto:craig.topper at gmail.com> >> <mailto:craig.topper at gmail.com<mailto:craig.topper at gmail.com>>> wrote: >> >> Probably in visitMUL in DAGCombiner.cpp to be target independent. Or >> in LowerMUL in X86ISelLowering.c...

...various target specific combines that we still have. > > At least ARM/AARCH64 and X86 have cases that can hopefully be > generalised and removed, but there will probably be a few legality/perf > issues that will occur. > > Simon. > >> On 14 Sep 2017, at 06:23, Craig Topper <craig.topper at gmail.com >> <mailto:craig.topper at gmail.com>> wrote: >> >> Probably in visitMUL in DAGCombiner.cpp to be target independent. Or >> in LowerMUL in X86ISelLowering.cpp to be X86 specific. >> >> Adding Simon. Simon, which were you t...

On Thu, Mar 6, 2014 at 3:47 PM, Craig Topper <craig.topper at gmail.com> wrote: > virtual bar *foo() = 0; > > where foo() also exists as pure in the base class. Clang-modernize has a > FIXME that says it can't find the "=0" to do the insert of override. > Does that mean we have a pure virtual function with...

On Thu, Mar 6, 2014 at 2:21 PM, Craig Topper <craig.topper at gmail.com> wrote: > It also doesn't do pure methods either. I think I don't quite understand what that means. Can you give me an example? > On Thursday, March 6, 2014, Rui Ueyama <ruiu at google.com> wrote: > >> After running the tool aginst...

...EX/EVEX_4V and TA. So, i restored my original instructions and for that i have to include bool HasTA = TSFlags & X86II::TA; in x86MCCodeEmitter.cpp then used this condition; if(HasTA) ++SrcRegNum; in order to emit binary correctly. Is it right? On Tue, Sep 5, 2017 at 5:45 AM, Craig Topper <craig.topper at gmail.com> wrote: > Put the TA's back. EVEX/EVEX_4V does not replace TA. They are for > different things. An EVEX/EVEX_4V instruction must use one of T8, TA, XOP8, > XOP9, XOPA. > > ~Craig > > On Mon, Sep 4, 2017 at 5:33 PM, hameeza ahmed <hahmed2...

Thank You, I changed TA to EVEX or EVEX_4V. But now i am getting following error: Invalid prefix! UNREACHABLE executed at /lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:647! On Tue, Sep 5, 2017 at 4:36 AM, Craig Topper <craig.topper at gmail.com> wrote: > Not all instructions can use EVEX_4V. Move instructions in particular > cannot because they don't have 2 sources. > > What do you intend to do with the binary output once you have it? You > don't seem to be targeting a particular bi...

...nizableInstr::emitInstructionSpecifier(): Assertion `numPhysicalOperands >= 2 + additionalOperands && numPhysicalOperands <= 4 + additionalOperands && "Unexpected number of operands for MRMSrcMemFrm"' failed What to do now? On Tue, Sep 5, 2017 at 4:23 AM, Craig Topper <craig.topper at gmail.com> wrote: > VEX_4V tells the encoder to use the VEX.vvvv field to encode one of the > operands. Without it the encoder assumes that the destination and one of > the sources must be the same physical register. > > TA indicates which of the opcode maps t...

+Hans Wennborg <hans at chromium.org> +tstellar at redhat.com <tstellar at redhat.com> for release thoughts.... On Mon, Jan 14, 2019 at 6:03 PM Craig Topper <craig.topper at gmail.com> wrote: > As far as I could tell, the only non-Intel contributions were from > mechanical API updates or fixing include paths when files moved to other > libraries for layering. > > I'm happy to do it on whatever side of the branch people prefer....

...er::RecognizableInstr::emitInstructionSpecifier(): Assertion `numPhysicalOperands >= 2 + additionalOperands && numPhysicalOperands <= 4 + additionalOperands && "Unexpected number of operands for MRMSrcMemFrm"' failed. On Mon, Aug 7, 2017 at 8:23 PM, Craig Topper <craig.topper at gmail.com> wrote: > masked_gather takes 3 inputs. not just an address. See the AVX512 pattern > is pasted earlier > > ~Craig > > On Mon, Aug 7, 2017 at 1:54 AM, hameeza ahmed <hahmed2305 at gmail.com> > wrote: > >> Changed it to; >>...

...hat we still have. > > > > At least ARM/AARCH64 and X86 have cases that can hopefully be > > generalised and removed, but there will probably be a few legality/perf > > issues that will occur. > > > > Simon. > > > >> On 14 Sep 2017, at 06:23, Craig Topper <craig.topper at gmail.com > >> <mailto:craig.topper at gmail.com>> wrote: > >> > >> Probably in visitMUL in DAGCombiner.cpp to be target independent. Or > >> in LowerMUL in X86ISelLowering.cpp to be X86 specific. > >> > >> Adding Si...

Yep. Makes sense to me. There's nothing to simplify or constant-fold about an alloca. -Hal On 04/12/2017 04:23 PM, Craig Topper wrote: > Ping > > ~Craig > > On Fri, Apr 7, 2017 at 1:25 PM, Craig Topper <craig.topper at gmail.com > <mailto:craig.topper at gmail.com>> wrote: > > I notice that GetUnderlyingObject has a few checks, but alloca > isn't one of them. Then it fall...

...that much harder (if at all) given that they'd need to clean up the build as well. Are there any other (non-Intel) devs who contributed significantly or might have specific opinions about this? Does it make more sense to this before or after the branch? On Mon, Jan 14, 2019 at 5:25 PM Craig Topper via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Patches up > > Clang: https://reviews.llvm.org/D56690 > LLVM: https://reviews.llvm.org/D56691 > > ~Craig > > > On Mon, Jan 14, 2019 at 3:51 PM Craig Topper <craig.topper at gmail.com> > wrote: > >&g...

Sorry to ask but what does it mean to put both? On Tue, Sep 5, 2017 at 4:01 AM, Craig Topper <craig.topper at gmail.com> wrote: > Leave TA. Put both. > > ~Craig > > On Mon, Sep 4, 2017 at 4:00 PM, hameeza ahmed <hahmed2305 at gmail.com> > wrote: > >> You are right. But when i defined my instruction as follows: >> def P_256B_VADD : I<0xE1, M...

...[(set VR_2048:$dst, _.KRCWM:$mask_wb, (v64i32 (GatherNode (VR_2048:$src1), _.KRCWM:$mask, VR_2048:$src2))], IIC_MOV_MEM>, TA; def: Pat<(v64f32 (GatherNode addr:$src2)), (GATHER_256B addr:$src2)>; Thank You On Mon, Aug 7, 2017 at 2:57 AM, Craig Topper <craig.topper at gmail.com> wrote: > masked_gather returns two results. The data and the modified mask. Note > the $dst and the $mask_wb in the pattern below. > > multiclass avx512_gather<bits<8> opc, string OpcodeStr, X86VectorVTInfo _, > X86...

There is in fact a transform out there somewhere that reverses yours. define i64 @foo(i64 %a) { %b = shl i64 %a, 5 %c = add i64 %b, %a ret i64 %c } becomes define i64 @foo(i64 %a) { %c = mul i64 %a, 33 ret i64 %c } ~Craig On Wed, Sep 13, 2017 at 10:11 AM, Craig Topper <craig.topper at gmail.com> wrote: > Your code seems fine. InstCombine can infinite loop if some other > transform is reversing your transform. Can you send the whole patch and a > test case? > > ~Craig > > On Wed, Sep 13, 2017 at 10:01 AM, Haidl, Michael via llvm-dev &l...

After running the tool aginst LLD, I realized that clang-modernize do not add "override" to virtual destructors. I think it's not intended but just that that case is not covered by the tool. On Wed, Mar 5, 2014 at 2:54 PM, Craig Topper <craig.topper at gmail.com> wrote: > Didn't realize that. I'll see if i can figure out how to make it delete > the virtual keyword. > > > On Wed, Mar 5, 2014 at 2:32 PM, Ben Langmuir <blangmuir at apple.com> wrote: > >> clang-modernize has a -format opti...

...r() and others. also in vectortype.h i >>> included these types for EVT but was unable to compile backend and getting >>> errors. >>> >>> Please help. >>> >>> Thank You >>> >>> >>> On Sun, Aug 6, 2017 at 8:42 PM, Craig Topper <craig.topper at gmail.com> >>> wrote: >>> >>>> You need a new instruction. And your scalar register size needs to >>>> match your vector element size. So GR32 instead of GR64 >>>> >>>> On Sun, Aug 6, 2017 at 5:44 AM hameeza ah...

Hi Craig, Thanks for the information. Can you point to the source that specifies tGPR to be R0 - R7? I tried to search in ARMInstrThumb.td but couldn’t find it. Thanks, - Jie On Apr 14, 2019, at 15:28, Craig Topper <craig.topper at gmail.com<mailto:craig.topper at gmail.com>> wrote: I believe there is probably a separate instruction in LLVM for thumb2 add. Probably starting with t2 instead of t. The definition of tADDi8 looks like this. Where tGPR specifically means R0-R7. def tADDi8 :...