similar to: [LLVMdev] getSetCC

We no longer have vsetcc, so the comment is wrong. The code looks incorrect. The fact that a vector is power-of-two does not guarantee anything about its legality. For example <128 x i64> would pass the condition in the code below, and die on most targets. From: Villmow, Micah [mailto:Micah.Villmow at amd.com] Sent: Friday, July 27, 2012 22:33 To: Rotem, Nadav; Developers Mailing List

if (N0.getOpcode() == ISD::SETCC && (LegalOperations || (!LegalOperations && VT.isPow2VectorType()))) But the comment right after it is: // sext(setcc) -> sext_in_reg(vsetcc) for vectors. // Only do this before legalize for now. if (VT.isVector() && !LegalOperations) { So, these optimizations are never safe in the general case if we can't

Hi Micah, I think that getSetCCResultType should only be called for legal types. Disabling it on isPow2VectorType is not the way to go because there are other illegal vector types which are pow-of-two. I suggest that you call it only after type-legalization. BTW, you can't set the LLVMTy yourself because you don't have access to the LLVMContext at that point. Nadav From:

I'm running into lots of problems with this call back. Mostly the problem occurs because this callback is used before types are legalized. However, the code generator does not have a 1-1 correspondence between all LLVM types and the codegen types. This leads to problems when getSetCCResultType is passed in an invalid type, but has a valid LLVM type attached to it. An example is <3 x

Here is a series of patches replacing EVT with MVT at a number of places in TargetLowering. The last two patches are related cleanups in SelectionDAGBuilder. /Patrik Hägglund > git log --stat --reverse origin/master.. commit 8dabe3eb005360347eabb86a2e88c3b6e9098ed5 Author: Patrik Hägglund <patrik.h.hagglund at ericsson.com> Date: Tue Dec 4 10:37:37 2012 +0100 Change

Hi, >> DAGCombiner::visitBRCOND() has code: >> >> SDValue N1 = N->getOperand(1); >> SDValue N2 = N->getOperand(2); >> >> ... >> >> SDNode *Trunc = 0; >> if (N1.getOpcode() == ISD::TRUNCATE&& N1.hasOneUse()) { >> // Look past truncate. >> Trunc = N1.getNode(); >> N1 = N1.getOperand(0);

On Dec 5, 2012, at 4:51 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 3 Dec 2012, at 23:45, Chris Lattner wrote: > >> Please do. MVT is cheaper than EVT and conceptually cleaner when dealing with physical machine types. EVT should only be used in parts of the code generator that are "pre-legalization" because they can represent arbitrary IR types.

On 3 Dec 2012, at 23:45, Chris Lattner wrote: > Please do. MVT is cheaper than EVT and conceptually cleaner when dealing with physical machine types. EVT should only be used in parts of the code generator that are "pre-legalization" because they can represent arbitrary IR types. Anything that takes a legal machine type should take an MVT. A side issue of this is that it is

Hi, I would like to restart the conversation regarding adding SVE support to LLVM. This time I am framing things from the code generation point of view because our immediate priority is llvm-mc support rather than auto-vectorisation. Can you please review the following text outlining MVT changes we would like to make so SVE instructions can be added to the AArch64 Target. My overriding

I was running into a problem with compiling llvm with gcc 4.4 on fedora 11 with --enable-optimized. I was seeing this warning dozens of times: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In member function ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h:362: warning: comparison always

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction

On Aug 18, 2009, at 11:50 AM, Erick Tryzelaar wrote: > I was running into a problem with compiling llvm with gcc 4.4 on > fedora 11 with --enable-optimized. I was seeing this warning dozens of > times: > > /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In > member function > ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: >

Hi, We've been working for the last two years on support for ARM's Scalable Vector Extension in LLVM, and we'd like to upstream our work. We've had to make several design decisions without community input, and would like to discuss the major changes we've made. To help with the discussions, I've attached a technical document (also in plain text below) to describe the

On Sep 30, 2010, at 2:13 AM, Heikki Kultala wrote: > Bill Wendling wrote: >> On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: >> >>> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >>> >>>> Our architecture has 1-bit boolean predicate registers. >>>> >>>> I've defined comparison >>>> >>>> def

Bill Wendling wrote: > On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote: > >> On 29 Sep 2010, at 06:25, Heikki Kultala wrote: >> >>> Our architecture has 1-bit boolean predicate registers. >>> >>> I've defined comparison >>> >>> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set

On Mar 21, 2013, at 11:26 AM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > I think in most cases it would be much simpler and safer to specify pattern types directly: > > def : Pat<(and (not i32:$src1), i32:$src2), > (ANDN32rr i32:$src1, i32:$src2)>; > def : Pat<(and (not i64:$src1), i64:$src2), > (ANDN64rr i64:$src1,

On Dec 3, 2012, at 1:14 PM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > There seems to be quite a few places where the EVT type is used, but the code asserts if the variable/parameter is assigned something else than an MVT. Are there any general objections to replace EVT with MVT in these cases? > > For example, a quick look at TargetLowering.h give me this

This post is related to the following post http://lists.llvm.org/pipermail/llvm-dev/2016-April/098823.html I'm still trying to compile a library with clang. But now I'm getting as assert in lib/CodeGen/TargetLoweringBase.cpp:1155: virtual llvm::EVT llvm::TargetLoweringBase::getSetCCResultType(llvm::LLVMContext&, llvm::EVT) const: Assertion `!VT.isVector() && "No default

There seems to be quite a few places where the EVT type is used, but the code asserts if the variable/parameter is assigned something else than an MVT. Are there any general objections to replace EVT with MVT in these cases? For example, a quick look at TargetLowering.h give me this list of (member) functions, taking an EVT parameter, that asserts if the argument is not an MVT: getRegClassFor,

On Wed, Aug 26, 2009 at 4:41 AM, Dan Sanduleac<sanduleac.dan at gmail.com> wrote: > Oh, I see. Didn't think of this, thanks! > > So, just to be clear, there's no binding overhead in Cython because the > functions defined there are pure python, right? (The function objects I > mean). Whereas the ones I defined in Boost are more expensive to call. > > On Wed, Aug