search for: targetloweringinfo

...on context and are not capable of being serialized into a string. Consider a query like "how expensive is a shuffle with this type on this shuffle mask". Clearly the only way to implement this is by having the target implement a virtual method call. Another sore point (for me) is that TargetLoweringInfo is a terrible mish-mash of stuff that things like LSR and things like SelectionDagLowering need. It definitely needs to be cleaned up and have some sanity beat into it (we don't want LSR thinking about MCExprs!), but this is a problem with the design of TargetLoweringInfo itself, not a problem...

..., conversions / >>> sign extension, etc. are not always supported) >>> - What alignment is necessary for loads and stores >>> - Is scalar-to-vector free? >> >> I think that this will be a really important API, but I strongly advocate that you model this after TargetLoweringInfo instead of TargetData. First, TargetData isn't actually a target API (it should be fixed, I filed PR11936 to track this). Second, targets will have to implement imperative code to return precise answers to questions. For example, you'll want something like "what is the cost of a shu...

...torized (division, conversions / > > sign extension, etc. are not always supported) > > - What alignment is necessary for loads and stores > > - Is scalar-to-vector free? > > I think that this will be a really important API, but I strongly advocate that you model this after TargetLoweringInfo instead of TargetData. First, TargetData isn't actually a target API (it should be fixed, I filed PR11936 to track this). Second, targets will have to implement imperative code to return precise answers to questions. For example, you'll want something like "what is the cost of a shu...

> On Feb 12, 2019, at 4:02 AM, Björn Pettersson A via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > (Sorry if this subject already has been discussed, but I could not find any clear rules/recommendations.) > > What would the recommendation be for acronyms (I’ve seen the rule about avoiding them unless they are “well known”, > but sometimes an acronym is useful, and we

...that have lambda/function type should follow the function-name spelling rules. - Class data members should have an "m_" prefix, so m_lower_case. - Initialisms and other abbreviations would be considered words for this purpose, so we have names such as: tli // Local variable for TargetLoweringInfo m_cgm // Data member for CodeGenModule - I don't have a good suggestion for file-static/global variables. Some people have suggested a "g_" prefix for globals, or possibly an "s_" prefix for class-static data. Regarding the transition: Some people have worried that...

...gest that we merge LLC and OPT > into a single tool that will drive both IR-level passes and the codegen. > *shrug* I really don't think this is necessary either. There's really no need for merging the two tools (and IMO would weaken the separation here). Why not just have TargetData/TargetLoweringInfo in opt? > I agree that it is not necessary for many optimizations. However, this is > absolutely needed for lower-level transformations such as strength > reduction. So, I plan to keep the current behavior that OPT has where if a > target information is not provided through the comma...

...>> sign extension, etc. are not always supported) > >>> - What alignment is necessary for loads and stores > >>> - Is scalar-to-vector free? > >> > >> I think that this will be a really important API, but I strongly advocate that you model this after TargetLoweringInfo instead of TargetData. First, TargetData isn't actually a target API (it should be fixed, I filed PR11936 to track this). Second, targets will have to implement imperative code to return precise answers to questions. For example, you'll want something like "what is the cost of a shu...

Is it possible to not make it 'Target*'? I'm spending a lot of time moving TargetData out, would hate to have to do it again at some point in the future for TargetVectorData. :) > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Nadav Rotem > Sent: Friday, October 05, 2012 1:23 PM > To: Eric

...fers from being spread across multiple dev threads plus a Phabricator review. Not optimal, but that's what it is. > > > - Initialisms and other abbreviations would be considered words for > > this purpose, so we have names such as: > > tli // Local variable for TargetLoweringInfo > > m_cgm // Data member for CodeGenModule > > I actually think we need something stronger. Acronyms should be > discouraged unless it's absolutely clear what it is. As has been > pointed out, "tli" means at least two common and very different things: > &qu...

On Oct 5, 2012, at 1:14 PM, Eric Christopher <echristo at gmail.com> wrote: > Nadav, > >>> Possibly, though I think TargetData should still be able to get you >>> what you want. >> >> >> TargetData does not have enough information for vectorization. For example, we need to ask the target if it has efficient "cos4" implementation or the

...>> sign extension, etc. are not always supported) > >>> - What alignment is necessary for loads and stores > >>> - Is scalar-to-vector free? > >> > >> I think that this will be a really important API, but I strongly advocate that you model this after TargetLoweringInfo instead of TargetData. First, TargetData isn't actually a target API (it should be fixed, I filed PR11936 to track this). Second, targets will have to implement imperative code to return precise answers to questions. For example, you'll want something like "what is the cost of a shu...

...lowrisc.org> wrote: >The relevant DAGCombine is controlled by a hook: `DAGCombiner::isMulAddWithConstProfitable`. > >It may be that, when optimising for size, this hook should take into account whether `c1*c2` fits into an add immediate, something that the DAGCombiner has access to via TargetLoweringInfo (but does not often use). > >I imagine any change here could have far reaching consequences in terms of introducing changes across lots of targets - I'm not sure what the best approach is to handle that. > >Sam > >> On 30 Jun 2020, at 2:08 pm, Sanjay Patel via llvm-dev &l...

...of operations can be vectorized (division, conversions / > sign extension, etc. are not always supported) > - What alignment is necessary for loads and stores > - Is scalar-to-vector free? I think that this will be a really important API, but I strongly advocate that you model this after TargetLoweringInfo instead of TargetData. First, TargetData isn't actually a target API (it should be fixed, I filed PR11936 to track this). Second, targets will have to implement imperative code to return precise answers to questions. For example, you'll want something like "what is the cost of a shu...

On Oct 5, 2012, at 12:08 AM, Nick Lewycky <nicholas at mxc.ca> wrote: > I absolutely think that we should have something like TargetData (now DataLayout) but for the vector types and operations. However, I'm not familiar with "Target Lowering Interface". Could you explain? I agree. Once we make the codegen accessible to the IR-level passes we need to start talking about

...flow has a direct impact on performance and removing the extra 'and' or 'or' in order to short circuit the conditional evaluation does not work for our target. So in order to make this type of instruction rely more on target specific information. I've added a new Boolean to the TargetLoweringInfo class called JumpIsExpensive along with accessor functions. Please review the patch and apply if acceptable. Thanks, Micah -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100722/4c120326/attachment.html&gt...

Hi, I am trying to rewrite loop addressing to suit my target. I wonder if there is a simple way to find out if the current SelectionDAG is a loop-body? I tried to rewrite LLVM code to do address arithmetic, ie %nextaddr = add i16* %curraddr, 4, but I could not find a way to make this work. thanks, Jonas -------------- next part -------------- An HTML attachment was scrubbed...

Yes - this has been in InstCombine for a long time: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/InstCombine/InstCombineMulDivRem.cpp#L268 We could say that the canonicalization should be reversed, but that probably uncovers more missing optimizations. The code size concern is legitimate. For example on x86, gcc asm is 2 bytes smaller on this example:

...bug, since it allows formation of FMAs with types like v16f32, as long as they legalize (via splitting, scalarization, promotion, etc.) to types that support FMAs; it turns out this case is explicitly tested for in test/CodeGen/X86/wide-fma-contraction.ll. So the proper solution, it seems, is for TargetLoweringInfo::isFMAFasterThanMulAndAdd implementations to check types and preconditions rather than depending on the caller to do so. The last in-tree target to implement this function, PowerPC, actually does check types, however, it only checks for the specific legal types, and therefore the following occurs:...

...;> into a single tool that will drive both IR-level passes and the codegen. >> > > *shrug* I really don't think this is necessary either. There's really > no need for > merging the two tools (and IMO would weaken the separation here). Why > not just have TargetData/TargetLoweringInfo in opt? If we want TLI in opt then we need to link it with the codegen. This makes OPT almost identical to LLC. IT will link with the same libraries and just differ in the command line arguments. > >> I agree that it is not necessary for many optimizations. However, this is >&gt...

Hello. In order to detect a problem in the initial selection DAG creation that I have in my back end I need to output detailed debug info from the SelectionDAG.cpp module with all the TableGen records that are being processed, and compare between a working back end and my buggy back end. I can debug by adding myself DEBUG() statements in the visit*() methods of the SelectionDAG.cpp