search for: targetloweringbase

...nge 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 pass which examines the function attributes and changes the pointer. So we would get: ImmutablePass * llvm::createBasicTargetTransformInfoPass(const TargetLoweringBase **TLI_) { return new BasicTTI(TLI); } we would add the variable T...

...09:43 AM, Reed Kotler wrote: > 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 need to be able to change the target lowering class that >> is used by BasicTTI >> >> For example we have a mips16 and...

...gt;> 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 need to be able to change the target lowering class that >>> is used by BasicTTI >>> >>&gt...

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

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 SetCC type for vectors!"' failed. I'm still learning LLVM, but unfortunately I don't know what this assert could...

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...) To un-break your build after this patch goes through,...

...p; s!=APFloat::opDivByZero) + if (!HasFPExceptions || (s!=APFloat::opInvalidOp && + s!=APFloat::opDivByZero)) { return getConstantFP(V1, VT); + } break; case ISD::FCOPYSIGN: V1.copySign(V2); Index: lib/CodeGen/TargetLoweringBase.cpp =================================================================== --- lib/CodeGen/TargetLoweringBase.cpp (revision 215148) +++ lib/CodeGen/TargetLoweringBase.cpp (working copy) @@ -705,6 +705,7 @@ JumpIsExpensive = false; PredictableSelectIsExpensive = false; MaskAndBranchFoldingIsLe...

It seems like this routine is not allocating any memory and could just be called a second time. Does anyone know if that is true? I looked at a bunch of it but did not want to create a memory leak by calling it again if it was doing a "new" indirectly somewhere. I've created a clearRegisterClasses method so that we can start all over. Then I would add register classes again and

...ling in SelectionDAGBuilder. Before moving on with target specific constraints, I'd like to discuss the general strategy for target hooks in GlobalISel. While most of these hooks on the SelectionDAG side live in the TargetLowering class, there is no corresponding GlobalISel subclass of the TargetLoweringBase class yet. Instead, the (one) existing GlobalISel hook currently lives in TargetLoweringBase. For lowering the target specific constraints, we'll have to add a new API that creates (G)MIR during IR translation. Personally I would prefer to have an InlineAsmLowering class, similar to the Cal...

...| (s!=APFloat::opInvalidOp && >> + s!=APFloat::opDivByZero)) { >> return getConstantFP(V1, VT); >> + } >> break; >> case ISD::FCOPYSIGN: >> V1.copySign(V2); >> Index: lib/CodeGen/TargetLoweringBase.cpp >> =================================================================== >> --- lib/CodeGen/TargetLoweringBase.cpp (revision 215148) >> +++ lib/CodeGen/TargetLoweringBase.cpp (working copy) >> @@ -705,6 +705,7 @@ >> JumpIsExpensive = false; >> Predictable...

...ntions 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 TargetLoweringBase::getPointerType ) and from then on there is no way to discriminate them, for example in the CallingConv.td file and so on. None of the functions in the above list are virtual and anyway it seems like a Bad Idea to just have getPointerType return iPTR or something l...

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

...hange any actual functionality. But it will pretty much completely break the utility of looking at only a single layer of blame. Fortunately we have nice tools like 'git blame' that can step incrementally back through time. If anyone is radically opposed to me cleaning up TargetLowering.h, TargetLoweringBase.cpp, and X86ISelLowering.{h,cpp}, shout. Otherwise, I will clean this up with a vengence. I've CC'ed piles of folks who are actively contributing and might be seriously impacted to make sure I don't really make life horrible for folks. -Chandler -------------- next part --------------...

...romotion to i64, this assertion is triggered. The other way around: a 32bit architecture (only i32 is valid) with doubles (f64) seems to work just fine. So, it seems that a 'TypeSoftenFloat' followed by an 'Expand' is valid (f64->i64->i32) Note: - this is for llvm-3.3 - In TargetLoweringBase.cpp , I find that (when f32 and f64 are not valid): -- the default action for 'f64' is to convert it into a 'i64' -- the default action for 'f32' is to convert it into a 'i32' Is this kind of support easy to add ? What would be the places that need to be updated ? (...

Looks like I have run into the same issue reported in: https://bugs.llvm.org/show_bug.cgi?id=20871 Is there a fix or work-around for it? The bug report seems to be still open. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/46c1282d/attachment.html>

Hi All, I am looking at a linker error under O2: undefined symbol __lshrdi3 I have two questions here: 1. Does that mean our libgcc (?) doesn't implement __lshrdi3? Or more generally, why I have such linker error? 2. Seems some operations are combined, and replaced with __lshrdi3 call. I am interested in when such libcall will be generated? Could you show me one

...d 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 need to be able to change the target lowering class that >>>> is used by BasicTTI &gt...

On 24 November 2015 at 13:06, Maxim Ostapenko <m.ostapenko at partner.samsung.com> wrote: > On 23/11/15 16:46, Jay Foad wrote: >> >> In LowerGET_DYNAMIC_AREA_OFFSET() you're calling >> MFI->getMaxCallFrameSize(), but it looks like that doesn't return useful >> information until after the PrologEpilogInserter's >>

...g an "optimization" pass be looking into specific types of SDNode doesn't seem ideal. But I need to introduce branches, and I don't think I can do that in the SelectionDAG. Branches in the middle of a basic block seems ... incorrect. Is there a good way to get ahold of the correct TargetLoweringBase from a pass? But there's still the layering issue, no? Oh, and sorry for the top posting. This is the email client I'm stuck with. From: Friedman, Eli [mailto:efriedma at codeaurora.org] Sent: Tuesday, April 03, 2018 1:56 PM To: Kevin Neal <Kevin.Neal at sas.com>; llvm-dev at lists....

...is sound important/reasonable? > > >> I was going to agree - but poking around, it looks like we need alignment >> too, at least (not sure if we need other things beyond size & alignment, >> nothing springs to mind but I don't know much about this stuff) - >> TargetLoweringBase::getByValTypeAlignment/DataLayout::getABITypeAlignment >> > > Nope, we don't, we have an align attribute. =D > Yep, seemed the align attribute wasn't always set in the frontend (& there's a comment in the backend where getByValTypeAlignment is called saying essential...