similar to: [LLVMdev] Your commit 149912 "Remove some dead code and tidy things up"...

On Feb 9, 2012, at 1:22 PM, Duncan Sands wrote: > Hi Chris, this was a very tempting commit to make, unfortunately it broke > pattern matching of vectors of booleans. The problem is that a > ConstantDataVector is only formed if the element type is one of i8, i16, etc. > So vectors of funky types, or not so funky types like i1, are no longer > matched. I noticed this while working

Hi Chris, >> Hi Chris, this was a very tempting commit to make, unfortunately it broke >> pattern matching of vectors of booleans. The problem is that a >> ConstantDataVector is only formed if the element type is one of i8, i16, etc. >> So vectors of funky types, or not so funky types like i1, are no longer >> matched. I noticed this while working on PR11948. The

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

----- Original Message ----- > 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

Does anybody else have an opinion on this issue? I'm planning to submit a patch which would add a new get method for ConstantDataVector taking an ArrayRef<Constant*> and use that in the few places in constant propagation where convertToFloat is used. Let me know if you think there is a more obvious way to do it. Right now the only way to create a ConstantDataVector are those method:

I don't see a way to create a ConstantDataVector from Constant or form APFloat though. Did I oversee that? Is the solution to had a new get function in ConstantDataVector to allow that? Any hint on what would be the right fix otherwise? Thomas -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednesday, January 14, 2015 10:30 AM To: Raoux, Thomas

On Mon, Jul 22, 2013 at 10:19 AM, Stephen Lin <swlin at post.harvard.edu> wrote: > 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.,

r261464 added a type called ConstantData to the Value hierarchy. This is a parent type for constants with no operands, such as i32 0 and null. Since then, I've removed most instances of iterating through the use-lists of an instance of ConstantData. I'd like to make this illegal. Since the users of ConstantData are spread across an LLVMContext, most code that looks at the users is

> On 2016-Sep-24, at 15:16, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Sep 24, 2016, at 3:06 PM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> r261464 added a type called ConstantData to the Value hierarchy. This >> is a parent type for constants with no operands, such as i32 0 and null. >>

Hi all, I came across an issue caused by the Call-Graph Simplify Pass. Here is a a small repro: ``` define double @foo(double %a1, double %a2, double %a3) #0 { entry: %a_mul = fmul double %a1, %a2 %a_cmp = fcmp ogt double %a3, %a_mul br i1 %a_cmp, label %a.then, label %a.end a.then: %a_div = fdiv double %a_mul, %a3 br label %a.end a.end: %a_factor = phi double [ %a_div, %a.then ],

[+current llvm-dev address] On 03/15/2017 09:23 AM, Hal Finkel wrote: > Hi Samuel, > > What are you taking about? ;) > > The only way to get a SIGFPE from a floating-point division by zero is > to modify the floating-point environment to enable those exceptions. > We don't support that (*). In the default (supported) environment, > floating point division is well

It’s true, I am working on this. I have committed the initial patch to add constrained intrinsics for the basic FP operations. This has the desired effect of preventing optimizations that would violate strict FP semantics with regard to rounding mode and exception status, but it also prevents many safe optimizations. Later this year I’ll be going through the code base and trying to teach

Hi folks, I'm hitting the below assertion failure when compiling this small piece of C code (repro.c, attached). My command line is: bin/clang --target=aarch64-linux-gnu -c -O2 repro.c clang is built from top of trunk as of this morning. It only happens at -O2, and it doesn't happen with the default target (x86_64). I tried to reproduce using just 'llc -O2' but didn't

> you can't, you can only get a ConstantAggregateZero.  This is actually kind of > annoying, and means that places expecting a ConstantArray have to remember to > also check for ConstantAggregateZero.  Perhaps there's a good reason for the > current design, but if not it would be great to eliminate this wart. Well, I think the main reason it so reduce the size of .ll / .bc when

Thanks for notifying me. Yes, this was a recent change. Taking a look now. On Wed, Jul 20, 2016 at 1:49 PM, Michael Kuperstein <mkuper at google.com> wrote: > +Sanjay, who touched this last. :-) > > On Wed, Jul 20, 2016 at 12:44 PM, Ismail Badawi (ibadawi) via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi folks, >> >> I'm hitting the

Hi Anton, >> you can't, you can only get a ConstantAggregateZero. This is actually kind of >> annoying, and means that places expecting a ConstantArray have to remember to >> also check for ConstantAggregateZero. Perhaps there's a good reason for the >> current design, but if not it would be great to eliminate this wart. > Well, I think the main reason it so

Sanjay: let me know if this is something that will apply to 3.9. Thanks, Hans On Wed, Jul 20, 2016 at 5:59 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Quick update - the bug existed before I refactored that chunk in > InstSimplify with: > https://reviews.llvm.org/rL275911 > > In fact, as discussed in https://reviews.llvm.org/D22537 - because we have a

Hi all. I propose to use wrapper for this kind of constant objects. Consider next code: Constant* C = reinterpret_cast<Constant*>(I->getOperand(idx)); Constant* ArrayItem; if (!isa<ConstantAggregateZero>(C)) ArrayItem = reinterpret_cast<Constant*>(I->getOperand(ArrItemIdx)); else ArrayItem = ZeroInt; Code analog within wrapper: ConstOrZero

Sure. David, what do you think about merging this to 3.9? Sanjay: are you saying I'd just apply that diff to InstructionSimplify.cpp, not InstCombineSelect.cpp? On Fri, Jul 22, 2016 at 7:08 AM, Sanjay Patel <spatel at rotateright.com> wrote: > Hi Hans - > > Yes, I think this is a good patch for 3.9 (cc'ing David Majnemer as code > owner). The functional change was

Fantastic! It's working! Thank you so much Craig!!! On Fri, Apr 7, 2017 at 6:05 PM, Craig Topper <craig.topper at gmail.com> wrote: > It should be VectorType::get(Type::getInt32Ty(Context),4). You need the > word "get" after VectorType:: > > ~Craig > > On Fri, Apr 7, 2017 at 6:01 PM, Michael Choi <choimichael103 at gmail.com> > wrote: >