Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] proposed change to class BasicTTI"
2013 Mar 22
4
[LLVMdev] proposed change to class BasicTTI
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
>
2013 Mar 22
0
[LLVMdev] proposed change to class BasicTTI
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
2013 Mar 22
0
[LLVMdev] proposed change to class BasicTTI
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
2013 Mar 28
3
[LLVMdev] proposed change to class BasicTTI and dual mode mips16/32 working
So I have dual mode 16/32 compilation on a per function basis working.
I need to clean up some things and then will push the change.
I managed to do everything without needing to change anything in target
independent code thus far. It was a fun puzzle to solve as to how to do
this using only the given APIs.
As for the BasicTransformInfoPassass, for this dual mode I'm using
2013 Jan 10
2
[LLVMdev] ARM vectorizer cost model
On 9 January 2013 17:10, Nadav Rotem <nrotem at apple.com> wrote:
> For example:
> "opt -cost-model -analyze dumper.ll -mtriple=thumbv7
> -mcpu=cortex-a15"
>
> I also run the vectorizer with -debug-only=loop-vectorize because it dumps
> the costs of all of the instructions with different vectorization factors,
> and it also detects the different kinds
2013 Mar 28
0
[LLVMdev] proposed change to class BasicTTI and dual mode mips16/32 working
Hi Reed,
On Mar 28, 2013, at 12:18 PM, Reed Kotler <rkotler at mips.com> wrote:
> As for the BasicTransformInfoPassass, for this dual mode I'm using createNoTargetTransformInfoPass right now.
So, MIPS does not need LSR, LowerSwitch and other optimizations that depend on TTI ?
> I will solve this issue of the BasicTransformInfoPass being immutable after this initial checking
2013 Mar 28
1
[LLVMdev] proposed change to class BasicTTI and dual mode mips16/32 working
On 03/28/2013 12:22 PM, Nadav Rotem wrote:
> Hi Reed,
>
> On Mar 28, 2013, at 12:18 PM, Reed Kotler <rkotler at mips.com
> <mailto:rkotler at mips.com>> wrote:
>
>> As for the BasicTransformInfoPassass, for this dual mode I'm using
>> createNoTargetTransformInfoPass right now.
>
> So, MIPS does not need LSR, LowerSwitch and other optimizations
2015 Jan 17
3
[LLVMdev] loop multiversioning
Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3
-mllvm -debug-pass=Arguments program.c -c
bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c
clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this
behavior is deprecated
Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa
-tbaa -scoped-noalias
2014 Aug 07
3
[LLVMdev] Proposal: Add a target lowering hook to state that target supports floating point exception behavior.
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
2013 Jan 09
0
[LLVMdev] ARM vectorizer cost model
Hi Renato,
> I'm interested in knowing how you'll work up the ARM cost model and how easy it'd be to split the work.
Yes, I am starting to work on the ARM cost model and I would appreciate any help in the form of: advice, performance measurements, patches, etc.
I tune the cost model by running the cost model analysis pass and I compare the output of the analysis to the output
2013 Jul 08
1
[LLVMdev] API break for out-of-tree targets implementing TargetLoweringBase::isFMAFasterThanMulAndAdd
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...)
2013 Jan 10
0
[LLVMdev] ARM vectorizer cost model
On Jan 10, 2013, at 2:19 PM, Renato Golin Linaro <renato.golin at linaro.org> wrote:
> I'm also thinking about the individual instructions cost (getArithmeticInstrCost, getShuffleCost, etc). That can be a simple and easily parallelized task. I got the A9 manual that has the cost of all instructions (including NEON and VFP), that should give us a head start.
Renato,
Thanks for
2013 Apr 01
0
[LLVMdev] proposed change to class BasicTTI and dual mode mips16/32 working
On 04/01/2013 12:31 PM, Chandler Carruth wrote:
> On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com
> <mailto:nrotem at apple.com>> wrote:
>
> IMHO the right way to handle target function attributes is to
> re-initialize the target machine and TTI for every function (if
> the attributes changed). Do you have another solution in mind ?
2013 Jan 11
2
[LLVMdev] ARM vectorizer cost model
On 10 January 2013 23:00, Nadav Rotem <nrotem at apple.com> wrote:
> Some of the costs for the arithmetic operations should be handled
> automatically by the BasicTTI (which asks TartetLowering if the type and
> operations are legal). We need to have cost tables for things like "trunk
> <4 x i64> to <4 x i8>" because even TLI does not know how custom
2018 Mar 08
1
how to discriminate pointers in calling conventions
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
2014 Aug 08
3
[LLVMdev] Proposal: Add a target lowering hook to state that target supports floating point exception behavior.
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
2016 Apr 29
3
Assert in TargetLoweringBase.cpp
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
2013 Jul 30
1
[LLVMdev] using f32 in a 64bit integer only architecture
Hi,
I am working on a 64bit architecture where only 'i64' is valid (no hardware floating point support)
and I am triggering a 'Promote may not follow Expand or Promote' assertion failure.
(TargetLowering.h : getTypeConversion)
When I look into it, I see that the conversion fails because llvm tries to convert a 'f32'
into a 'i32' through a TypeSoftenFloat.
As i32
2020 Apr 06
4
[GlobalISel] Extended inline assembler support
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
2013 Apr 01
3
[LLVMdev] proposed change to class BasicTTI and dual mode mips16/32 working
On Thu, Mar 28, 2013 at 12:22 PM, Nadav Rotem <nrotem at apple.com> wrote:
> IMHO the right way to handle target function attributes is to
> re-initialize the target machine and TTI for every function (if the
> attributes changed). Do you have another solution in mind ?
I don't really understand this.
TargetMachine and TTI may be quite expensive to initialize. Doing so for