search for: patternmatch

...%cond, <i1 1, i1 1> %s = select <2 x i1> %invert, <2 x i32> <i32 0, i32 0>, <2 x i32> <i32 1, i32 1> %c = icmp ne <2 x i32> %s, <i32 0, i32 0> ret <2 x i1> %c ; CHECK: ret <2 x i1> %cond } Ciao, Duncan. > Index: PatternMatch.h > =================================================================== > --- PatternMatch.h (revision 149911) > +++ PatternMatch.h (revision 149912) > @@ -98,13 +98,6 @@ > Res = &CI->getValue(); > return true; > } > - // FIXME: Remove...

Hi llvm-dev, Does LLVM's PatternMatch library support matching on GetElementPointer Instructions? I can't find anything in the API that looks promising. Thank you! Eli

...CK: ret <2 x i1> %cond > } Hi Duncan, I'm ok with adding this back. OTOH, it might be better to allow ConstantData to work with i1's. Would just handling i1 be enough, or do you think it's worth it to go more general? -Chris > > Ciao, Duncan. > >> Index: PatternMatch.h >> =================================================================== >> --- PatternMatch.h (revision 149911) >> +++ PatternMatch.h (revision 149912) >> @@ -98,13 +98,6 @@ >> Res = &CI->getValue(); >> return true; >> } &g...

...nstant is only made up of numbers, then it's ConstantData. I think what I'll do is revert this commit for the moment, and see if I can find a reasonable way of implementing the general case. Ciao, Duncan. > > -Chris > >> >> Ciao, Duncan. >> >>> Index: PatternMatch.h >>> =================================================================== >>> --- PatternMatch.h (revision 149911) >>> +++ PatternMatch.h (revision 149912) >>> @@ -98,13 +98,6 @@ >>> Res =&CI->getValue(); >>> retur...

...req 3 is that there may be compile time savings available if we can describe in a declarative style the combines we want to do, like it’s currently possible with tablegen patterns. This hasn’t been proven out yet, but consider an alternative where we use the machine instruction equivalent of the IR/PatternMatch tooling which allows easy and expressive matching of IR sub-trees. A concern I have with using that as the main approach to writing combines is that it’s easy to add new matchers in an routine which re-computes information that’s previously been computed in previous match() attempts. This form of b...

...n:   https://reviews.llvm.org/D57504 The prototype demonstrates: -  Predicated vector intrinsics with an explicit mask and vector length parameter on IR level. -  First-class predicated SDNodes on ISel level. Mask and vector length are value operands. -  An incremental strategy to generalize PatternMatch/InstCombine/InstSimplify and DAGCombiner to work on both regular instructions and EVL intrinsics. -  DAGCombiner example: FMA fusion. -  InstCombine/InstSimplify example: FSub pattern re-writes. -  Early experiments on the LNT test suite (Clang static release, O3 -ffast-math) indicate that compil...

Hey, First time using LLVM's git repo. Does 'git llvm push' take a really long time to work? I've tried to push a couple of times now and receive a message like: <scrubbed> llvm-project/llvm> git llvm push Pushing 1 commit: 2159c44 Update PatternMatcher for FNeg Committed 2159c44 to svn. <scrubbed> llvm-project/llvm> The svn repo never seems to update though. Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190503/7e75f131/attachment.h...

...an Operator > > > object. That's undefined behavior, right? > > Yes. > Well then I guess the next step is how to fix it. I tried removing the method and rebuilding. The resulting compilation errors were easily fixed by changing the few occurrences in: include/llvm/Support/PatternMatch.h lib/Analysis/BasicAliasAnalysis.cpp lib/Analysis/ScalarEvolution.cpp lib/Analysis/ValueTracking.cpp lib/CodeGen/ScheduleDAGInstrs.cpp lib/CodeGen/SelectionDAG/FastISel.cpp to use the static variant of Operator::getOpcode(). (This was with 3.1; trunk may be different.) I suppose one could a...

>> In this function, the `this` pointer is not pointing at an Operator >> object. That's undefined behavior, right? > > Yes. Well then I guess the next step is how to fix it. Maybe someone with a bit more experience with the Operator code and how it is used could make a suggestion? (I just stumbled upon this code yesterday while doing some refactoring, so I'm not

...g LLVM's git repo. Does 'git llvm push' take a really long >> time to work? I've tried to push a couple of times now and receive a >> message like: >> >> <scrubbed> llvm-project/llvm> git llvm push >> Pushing 1 commit: >> 2159c44 Update PatternMatcher for FNeg >> >> Committed 2159c44 to svn. >> <scrubbed> llvm-project/llvm> >> >> The svn repo never seems to update though. Any ideas? >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.ll...

...or ConstantDataVector with all zeros of either sign, or > a zero initializer... > > Anyone have any thoughts, and/or can point me to somewhere where this > kind of thing is already implemented? We do already have Constant::isZeroValue(). There's also m_SpecificFP and m_AnyZero in PatternMatch.h. -Eli

...req 3 is that there may be compile time savings available if we can describe in a declarative style the combines we want to do, like it’s currently possible with tablegen patterns. This hasn’t been proven out yet, but consider an alternative where we use the machine instruction equivalent of the IR/PatternMatch tooling which allows easy and expressive matching of IR sub-trees. A concern I have with using that as the main approach to writing combines is that it’s easy to add new matchers in an routine which re-computes information that’s previously been computed in previous match() attempts. This form of b...

On Dec 23, 2014, at 10:28 AM, Chris Bieneman <beanz at apple.com> wrote: >>> It should be straight-forward to have something like LLVMInitializeX86Target/RegisterTargetMachine install the intrinsics into a registry. >> >> I tried doing that a few years ago. It’s not nearly as easy as it sounds because we’ve got hardcoded references to various target intrinsics scattered

...e "SelectInst::Create" phase. The problem is because B is now a Constant with "-2" as its value, so it has 0 operands. It appears that the m_Not() match is changing the value of B during this call. Is this intentional? This happens in the "bind_ty" template in PatternMatch.h: template<typename Class> struct bind_ty { Class *&VR; bind_ty(Class *&V) : VR(V) {} template<typename ITy> bool match(ITy *V) { if (Class *CV = dyn_cast<Class>(V)) { VR = CV; return true; } return false; } }; Why are we tak...

> I tried removing the method and rebuilding. The resulting compilation errors were easily fixed by changing the few occurrences in: > include/llvm/Support/PatternMatch.h > lib/Analysis/BasicAliasAnalysis.cpp > lib/Analysis/ScalarEvolution.cpp > lib/Analysis/ValueTracking.cpp > lib/CodeGen/ScheduleDAGInstrs.cpp > lib/CodeGen/SelectionDAG/FastISel.cpp > to use the static variant of Operator::getOpcode(). (T...

...t grep Intrinsic:: | wc > 3364 12286 281078 > > The vast majority of those 3,364 lines have hardcoded references to specific intrinsics. Many of them are used in contexts where you can’t easily insert a strcmp (e.g., case values in large switch statements, or worse, the m_Intrinsic PatternMatch templates). I don’t find this convincing. It should be simple to introduce a new m_Intrinsic PatternMatch template that takes a string. The switches are also straight-forward. In BasicAA, for example, instead of: switch (II->getIntrinsicID()) { default: break; case Intrinsic::mem...

...req 3 is that there may be compile time savings available if we can describe in a declarative style the combines we want to do, like it’s currently possible with tablegen patterns. This hasn’t been proven out yet, but consider an alternative where we use the machine instruction equivalent of the IR/PatternMatch tooling which allows easy and expressive matching of IR sub-trees. A concern I have with using that as the main approach to writing combines is that it’s easy to add new matchers in an routine which re-computes information that’s previously been computed in previous match() attempts. This form of b...

Hi, I noticed that ConstantFP::get automatically returns the appropriately types Constant depending on the LLVM type passed in (i.e. if called with a vector, it returns a splat vector with the given constant). Is there any simple way to do the inverse of this function? i.e., given a llvm::Value, check whether it is either a scalar of the given constant value or a splat vector with the given

...emonstrates: > > -  Predicated vector intrinsics with an explicit mask and vector > length parameter on IR level. > -  First-class predicated SDNodes on ISel level. Mask and vector > length are value operands. > -  An incremental strategy to generalize > PatternMatch/InstCombine/InstSimplify and DAGCombiner to work on > both regular instructions and EVL intrinsics. > -  DAGCombiner example: FMA fusion. > -  InstCombine/InstSimplify example: FSub pattern re-writes. > -  Early experiments on the LNT test suite (Clang static release, &g...

...t; phase. > The problem is because B is now a Constant with "-2" as its value, so > it has 0 operands. It appears that the m_Not() match is changing the > value of B during this call. > > Is this intentional? This happens in the "bind_ty" template in > PatternMatch.h: > > template<typename Class> > struct bind_ty { > Class *&VR; > bind_ty(Class *&V) : VR(V) {} > > template<typename ITy> > bool match(ITy *V) { > if (Class *CV = dyn_cast<Class>(V)) { > VR = CV; > return...