similar to: [LLVMdev] using f32 in a 64bit integer only architecture

For being able to change subtargets within a compilation unit, among other things, I need to be able to change the target lowering class that is used by BasicTTI For example we have a mips16 and non mips16 version. On the original call that creates this class, I'd like to pass the address of the address of the TargetLoweringBase class. That way I can insert a function pass before this

Another way to do this would to be to have a reset virtual function which is passed the Function, and the address of TLI so that it could be modified. This seems somewhat cleaner. The reset virtual function would be added to base class TargetLoweringBase. On 03/22/2013 09:22 AM, reed kotler wrote: > For being able to change subtargets within a compilation unit, among > other things, I

Just realized that BasicTransformInfoClass is an immutable pass. Not sure how to reconcile this with fact that there will be different answers needed depending on the subtarget. Seems like BasicTansformInfoClass should become a function pass that does not modify anything. On 03/22/2013 09:43 AM, Reed Kotler wrote: > Another way to do this would to be to have a reset virtual function >

Hi Reed, We will need to reconstruct the target machine and the TTI chain when the function attributes change. We currently don't have code for doing that but I suggest that you talk with Bill Wendling about the best way to implement this. Thanks, Nadav On Mar 22, 2013, at 11:30 AM, Reed Kotler <rkotler at mips.com> wrote: > Just realized that BasicTransformInfoClass is an

Hi Hal, On Fri, Apr 4, 2014 at 12:44 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Jeroen Dobbelaere" <jeroen.dobbelaere at gmail.com> > [... ] > > I am trying to get llvm working for an architecture that has 64bit > > registers, but 32bit addresses. > > Because of that, I want the pointers to also be

Hi, I am trying to get llvm working for an architecture that has 64bit registers, but 32bit addresses. Because of that, I want the pointers to also be 32bit, although they will live in a 64 bit register. On the frontend, I do not encounter any issues, but when I provide a ... "p:32:32:32" ... DataLayout specification to the backend, things get ugly: - SelectionDag is producing a

Hi Hal, On Fri, Apr 4, 2014 at 1:22 PM, Hal Finkel <hfinkel at anl.gov> wrote: > [..] > Agreed; but what does your *ISelLowering::getPointerTy() function look > like? Did you override the default implementation? I wonder if returning > MVT::i64 from this function will make things work for you. > > -Hal > > I actually missed implementing this one. But, depending

Hello All, the patch below adds a target lowering hook to state that the target supports (or not) floating point exception behavior. The patch is small and contains one possible use for the hook (folding potentially exception raising fp operations). Any comments? Thanks Pedro -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: opensource1.txt

Hi Renato, Indeed problem is with generation of vmla.f64. Affected benchmark is MILC from SPEC 2006 suite and disabling vmlx forwarding gives a 10% speed-up on complete benchmark execution ! So it is worth a try. Now going back to vmla generation through LLMV intrinsic usage. I've looked at .td file and it seems to me that when there is a "pattern" to generate instruction, no

Hello, To any out-of-tree targets, please be aware that I intend to commit a patch that will break the build of any target implementing TargetLoweringBase::isFMAFasterThanMulAndAdd, for the reasons described below. (Basically, the current interface definition is broken and not followed, and no in-tree target was doing the right thing with it, so it is unlikely any out-of-tree target is either...)

On 11 February 2013 15:51, Sebastien DELDON-GNB <sebastien.deldon at st.com>wrote: > Indeed problem is with generation of vmla.f64. Affected benchmark is MILC > from SPEC 2006 suite and disabling vmlx forwarding gives a 10% speed-up on > complete benchmark execution ! So it is worth a try. > Hi Sebastien, Ineed, worth having a look. Including Bob Wilson (who introduced the

I have a target whose calling conventions specify that pointer-typed arguments are passed in different registers than same-sized integers. It appears that in the SelectionDAGBuilder, arguments/formals with pointer type are lowered to the corresponding integer MVT (via this path: SelectionDAGISel::LowerArguments llvm::ComputeValueVTs TargetLoweringBase::getValueType

I assume you meant to ask for ports that *don’t* support floating point exceptions. To my knowledge, neither R600 nor NVPTX support floating point exceptions. —Owen > On Aug 8, 2014, at 2:41 PM, Eric Christopher <echristo at gmail.com> wrote: > > There's a lot of cut and paste in those routines. Can you do something > to unify it a bit? Also, do we have any ports that

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

Hi! So far, GlobalISel only supports very basic inline assembler constructs (no input/output operands, only simple memory clobbers). In [0], I'm adding support for generic register, immediate, memory and clobber constraints. The code is more or less a direct port from the handling in SelectionDAGBuilder. Before moving on with target specific constraints, I'd like to discuss the

Hi, I am working on a patch for CodeGenPrepare, which introduces a use of TargetLoweringBase::InstructionOpcodeToISD (see [1] for the details). This is usual for CodeGenPrepare to use the TargetLowering class when it is available, however, using this particular function creates linking problems. ** Context ** The TargetLowering class is part of libLLVMCodeGen, which means that in theory every

Folding for conversions: F32/64->(U16/32, S16/32) and (U16/32, S16/32)->F32 No piglit regressions observed on nv50 and nvc0! Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- V2: fix usage of wrong variable V3: enable F64 support V4: - disable F64 support again - handle saturate flag: clamp to min/max if needed

In theory, the backend should choose the best instructions for the selected target processor. VMLA is not always the best choice. Lang Hames did some measurements a while back to come up with the current behavior, but I don't remember exactly what he found. CC'ing Lang. On Feb 11, 2013, at 8:12 AM, Renato Golin <renato.golin at linaro.org> wrote: > On 11 February 2013 15:51,

Hi Bob, Seb, Renalto, My VMLA performance work was on Swift, rather than Cortex-A9. Sebastian - is vmlx-forwarding really the only variable you changed between your tests? As far as I can see the VMLx forwarding attribute only exists to restrict the application of one DAG combine optimization: PerformVMULCombine in ARMISelLowering.cpp, which turns (A + B) * C into (A * C) + (B * C). This

I'm building this with llvm-c, and accessing these intrinsics via calling the intrinsic as if it were a function. class F_SREG<string OpStr, NVPTXRegClass regclassOut, Intrinsic IntOp> : NVPTXInst<(outs regclassOut:$dst), (ins), OpStr, [(set regclassOut:$dst, (IntOp))]>; def INT_PTX_SREG_TID_X : F_SREG<"mov.u32 \t$dst, %tid.x;",