similar to: [LLVMdev] What is HexagonTargetMachine::addPassesForOptimizations for?

On 4/30/2014 8:45 AM, Rafael Espíndola wrote: > On 30 April 2014 00:52, Craig Topper <craig.topper at gmail.com> wrote: >> This function is marked virtual but doesn't override anything, doesn't have >> any overrides, and has no in tree callers. Can it be removed? > > Given that it is dead, yes :-) > It used to be called from clang, from

On 4/30/2014 2:00 PM, Matthew Curtis wrote: > On 4/30/2014 9:01 AM, Krzysztof Parzyszek wrote: >> On 4/30/2014 8:45 AM, Rafael Espíndola wrote: >>> On 30 April 2014 00:52, Craig Topper <craig.topper at gmail.com> wrote: >>>> This function is marked virtual but doesn't override anything, >>>> doesn't have >>>> any overrides, and

On 4/30/2014 5:24 PM, Craig Topper wrote: > Pranav, can you remove it? > Yes, I'll remove it. Pranav -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

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

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

clang-modernize has a -format option that will run clang-format on the code it changes. Ben On Mar 5, 2014, at 2:26 PM, Craig Topper <craig.topper at gmail.com> wrote: > clang-modernize can add the 'override', but it can't currently delete 'virtual'. It will also potentially overflow 80 columns. And if it removed virtual it would fail to align a second line of

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,

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

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:

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

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

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

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

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

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

On Wed, Mar 5, 2014 at 1:02 PM, Marshall Clow <mclow.lists at gmail.com> wrote: > > On Mar 5, 2014, at 10:29 AM, Chris Lattner <clattner at apple.com> wrote: > > > On Mar 5, 2014, at 9:53 AM, David Blaikie <dblaikie at gmail.com> wrote: > > It might be reasonable to warn if a class has both a function marked > 'override' and a function that

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,