search for: x86tti

...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 -assumption-tracker -basicaa -verify -add-discriminators -simplifycfg -domtree -sroa -early-cse -lower-expect Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias -assumption-tracker -basicaa -verify-di -ipsccp...

...iant of the bug and learned about -plugin-opt=-debug-pass=Arguments which I infer from comments is intended to built arguments to “opt” however I found that some of the arguments don’t seem to be quite correct. I assume this just minor bit rot. bin/opt -o pass1.bc -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias -assumption-tracker -basicaa -verify -verify-di -ipsccp -globalopt -c\ onstmerge -deadargelim -instcombine -basiccg -inline-cost -inline -prune-eh -globalopt -globaldce -basiccg -argpromotion -instcombine -lazy-value-info -jump-threading -domt\ ree -sroa...

...stances kept in the LLVMContext? This would also allow them to be cached in the same way, and it would make them available to any part of the middle or backend that wanted them. We currently have something that looks like: IR Transform (links with) -> TargetTransformInfo (dynamic call) -> X86TTI (links with) -> X86Subtarget I was thinking of directly replacing X86Subtarget as such: IR Transform (links with) -> TargetTransformInfo (dynamic call) -> X86TTI (links with) -> TargetMachine (provides) -> CGContext So CGContext could still live inside libTarget. CGConte...

...tion that can work with TTI? I don’t think there was any objection to putting CGContext in TargetMachine, except that we have too many layers of abstraction, which you said will be cleaned up eventually: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> TargetMachine > (provides) -> CGContext > > This seems fine to me? Ok. Future work: do something simpler for TTI, as opposed to analysis groups. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.or...

On Thu, Dec 5, 2013 at 4:16 PM, Andrew Trick <atrick at apple.com> wrote: > We currently have something that looks like: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> X86Subtarget > > I was thinking of directly replacing X86Subtarget as such: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> TargetMachine > (provides) -> CGContext > > So...

.... Do we have a solution that can work with TTI? I don’t think there was any objection to putting CGContext in TargetMachine, except that we have too many layers of abstraction, which you said will be cleaned up eventually: IR Transform (links with) -> TargetTransformInfo (dynamic call) -> X86TTI (links with) -> TargetMachine (provides) -> CGContext -Andy > > > On Thu, Dec 5, 2013 at 6:19 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > > > On Mon, Dec 2, 2013 at 4:25 PM, Andrew Trick <atrick at apple.com> wrote: > > On Nov 25, 20...

...nk > <4 x i64> to <4 x i8>" because even TLI does not know how custom operations > gets lowered. > BasicTTI::getCastInstrCost() assumes that they're free, which is probably so that it returns something that doesn't break the cost model. I can see the X86 table in X86TTI::getCastInstrCost(), are you expecting something similar? I shall investigate all possible combinations and try to build a similar model. That also means we should re-using the X86TypeConversionCostTblEntry as a more generic structure? cheers, --renato -------------- next part -------------- An H...

...ike this: "opt -o /dev/null -S test.ll -load libPlaydep.so > -O3 -playdep --debug-pass=Structure" > And the output: > > opt -o /dev/null test.ll -S -load ./libPlaydep.so -O3 -playdep > --debug-pass=Structure > Pass Arguments: -targetlibinfo -datalayout -notti -basictti -x86tti -no-aa > -tbaa -scoped-noalias -assumption-cache-tracker -basicaa -verify-di -ipsccp > -globalopt -deadargelim -domtree -instcombine -simplifycfg -basiccg > -prune-eh -inline-cost -inline -functionattrs -argpromotion -sroa -domtree > -early-cse -lazy-value-info -jump-threading -correlat...

On Mon, Dec 2, 2013 at 4:25 PM, Andrew Trick <atrick at apple.com> wrote: > > On Nov 25, 2013, at 4:40 PM, Dan Gohman <dan433584 at gmail.com> wrote: > > > Hello llvm-dev, > > > > Following up on the "CodeGen Context" discussion that was started, > attached is patch which implements a pretty minimal skeleton of a CGContext > implementation.

...7 PM, Chandler Carruth <chandlerc at google.com> wrote: > > On Thu, Dec 5, 2013 at 4:16 PM, Andrew Trick <atrick at apple.com> wrote: > We currently have something that looks like: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> X86Subtarget > > I was thinking of directly replacing X86Subtarget as such: > > IR Transform > (links with) -> TargetTransformInfo > (dynamic call) -> X86TTI > (links with) -> TargetMachine > (provides) -> CGContext > >...

----- Original Message ----- > From: "Jingyue Wu" <jingyue at google.com> > To: "songlh" <songlh at cs.wisc.edu>, llvmdev at cs.uiuc.edu > Sent: Wednesday, October 15, 2014 2:50:12 PM > Subject: Re: [LLVMdev] how to choose which alias analysis used in my pass? > > > Isn't -basicaa the default alias analysis already? No, -basicaa is added

On Jan 3, 2015, at 11:52 PM, Bill Wendling <isanbard at gmail.com> wrote: > On Jan 2, 2015, at 8:32 PM, David Callahan <dcallahan at fb.com> wrote: > >> Hi, >> >> I am new to the LLVM dev community so forgive a perhaps obvious question. I am looking at bug 17623 which is an LTO/optimizer interaction bug. I am working on a Mac with Xcode installed but have

Hi, I try to use MemoryDependenceAnalysis in a pass to analyse a simple function: void fct (int *restrict*restrict M, int *restrict*restrict L) { S1: M[1][1] = 1; S2: L[2][2] = 2; } When I iterate over MemoryDependenceAnalysis on the S2 statement, I get the load instruction for the first depth of the array, that’s ok. But I get also the load and store for the S1 statement. I assume the

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

...;4 x i64> to <4 x i8>" because even TLI does not know how custom operations gets lowered. > > BasicTTI::getCastInstrCost() assumes that they're free, which is probably so that it returns something that doesn't break the cost model. > > I can see the X86 table in X86TTI::getCastInstrCost(), are you expecting something similar? I shall investigate all possible combinations and try to build a similar model. > Yes. I am expecting something similar. > That also means we should re-using the X86TypeConversionCostTblEntry as a more generic structure? Yes, it w...

...here it can work, it leaves allocated but unutilized registers. Doesn't work. In fact, I'd suggest the Arm backend adopt my approach. So firstly, I think the best way to solve this problem is to avoid this problem in the first place. Just don't hoist these values. For the X86 backend, X86TTI::getIntImmCost() in X86TargetTransformInfo.cpp is an overridden function. Just mark these 1 bit masks there as TCC_Free: // Don't hoist 1 bit masks. They'll probably be used for BT, BTS, BTC. if (Imm.isPowerOf2()) // this could be limited to bits 32-63 return TCC_Free; This...

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

...that TTI and TargetMachine are broken in the presence of function attributes. And IR passes are using both TTI and TargetMachine directly. My first suggestion was a straightforward fix, but builds more layers of complexity: IR Transform (links with) -> TargetTransformInfo (dynamic call) -> X86TTI (links with) -> TargetMachine (provides) -> CGContext (IR passes that use TargetMachine directly would need to be fixed to use CGContext). I like Dan’s suggestion of using LLVMContext as the container instead, but we have to think about how that fits with existing TTI—when should a pa...

On Thu, Dec 5, 2013 at 5:04 PM, Andrew Trick <atrick at apple.com> wrote: > Right. On the flip side, some passes should be able to make hard queries > against target/subtarget that fail if the driver doesn’t initialize them. I > don’t want any way to accidentally run the vectorizer or LSR without > initializing my subtarget info. Also, I want to prevent early passes from >

...idest register is: 32 bits. This strongly looks like no target has added a target transform info pass so we default to NoTTI. But, it could also be that you don’t have the right sub target (in which case you need to set the right cpu, “-mcpu” in opt, when the target machine is created): unsigned X86TTI::getRegisterBitWidth(bool Vector) const { if (Vector) { if (ST->hasAVX()) return 256; if (ST->hasSSE1()) return 128; return 0; } if (ST->is64Bit()) return 64; return 32; } > > It's not picking the target information, although I tried with and > wi...