search for: toppers

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

This conversation has (partially) moved on to D37896 now, but if possible I was hoping that we could perform 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,

Hi Sanjay, thanks for enlighten me on terms of tests. I assume I have to run the test-suite benchmarks to check for regressions? Is there a guide to get the metrics from the benchmarks? Cheers, Michael BTW the beginner tag for bugs was really a good idea to get started with contributing to llvm. On Tue, Sep 19, 2017 at 3:58 PM +0200, "Sanjay Patel" <spatel at

I am currently improving the D37896 to include the suggestions from Chad. However, running the lit checks for the x86 backend I observe some changes in the generated MC, e.g.: llvm/test/CodeGen/X86/lea-3.ll:13:10: error: expected string not found in input ; CHECK: leal ([[A0]],[[A0]],2), %eax ^ <stdin>:10:2: note: scanning from here orq %rdi, %rax ^ <stdin>:10:2:

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 implementation in Clang/LLVM? If so, I feel it's a

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 LLD, I realized that clang-modernize do not >> add

I was getting same error when i keep both EVEX/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: >

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. >

Thank You. I used EVEX_4V with all the instructions. I replaced TA and EVEX both with EVEX_4V. Now, I am getting following error: llvm-tblgen: /utils/TableGen/X86RecognizableInstr.cpp:687: void llvm::X86Disassembler::RecognizableInstr::emitInstructionSpecifier(): Assertion `numPhysicalOperands >= 2 + additionalOperands && numPhysicalOperands <= 4 + additionalOperands &&

+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. > >

Thank You. Still getting errors.I have modified my instructions as you said as follows: def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst, VK64WM:$mask_wb), (ins VR_2048:$src1, VK64WM:$mask, i2048mem:$src2), "GATHER_256B\t{$src2, {$dst} {${mask}}|${dst} {${mask}}, $src2}", [(set VR_2048:$dst, VK64WM:$mask_wb, (v64i32 (masked_gather

For the tests that are changing, you should see if those changes are improvements, regressions, or neutral. This is unfortunately not always obvious for x86 asm, so feel free to just post those diffs in an updated version of the patch at D37896. If the test files have auto-generated assertions (look for this string on the first line of the test file: "NOTE: Assertions have been autogenerated

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 >

FWIW, I support this especially as it doesn't build. If someone wants to revive it, removing it won't actually make 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

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,

Hello, I did as you said, Please tell me whether the following correct now?? def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst, _.KRCWM:$mask_wb), (VR_2048:$src1, _.KRCWM:$mask, ins i2048mem:$src2), "GATHER_256B\t{$src2, {$dst}{${mask}}|${dst} {${mask}}, $src2}"), [(set VR_2048:$dst, _.KRCWM:$mask_wb, (v64i32 (GatherNode

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

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

i want to implement gather for v64i32. i wrote following code. def GATHER_256B : I<0x68, MRMSrcMem, (outs VR_2048:$dst), (ins i2048mem:$src), "GATHER_256B\t{$src, $dst|$dst, $src}", [(set VR_2048:$dst, (v64i32 (masked_gather addr:$src)))], IIC_MOV_MEM>, TA; def: Pat<(v64f32 (masked_gather addr:$src)), (GATHER_256B

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