Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Inverse of ConstantFP::get and similar functions?"
2013 Jul 22
0
[LLVMdev] Inverse of ConstantFP::get and similar functions?
----- 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
2013 Jul 22
0
[LLVMdev] Inverse of ConstantFP::get and similar functions?
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.,
2013 Jul 23
0
[LLVMdev] Inverse of ConstantFP::get and similar functions?
Hi Stephen,
On 22/07/13 19:19, Stephen Lin 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.,
> given a llvm::Value, check
2015 Jan 20
2
[LLVMdev] Bug in InsertElement constant propagation?
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:
2012 Feb 09
2
[LLVMdev] Your commit 149912 "Remove some dead code and tidy things up"...
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 good thing is that
the testcase there no longer crashes
2012 Feb 10
0
[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
2012 Feb 10
1
[LLVMdev] Your commit 149912 "Remove some dead code and tidy things up"...
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
2015 Jan 15
2
[LLVMdev] Bug in InsertElement constant propagation?
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
2010 Mar 15
3
[LLVMdev] [patch] Writing ConstantUnions
Hello,
I noticed a bit of a gap in the current code for unions: a
ConstantUnion cannot be written out to .ll.
Hopefully I'm not stepping on Talin's toes by posting this, it's a
fairly straightforward adaptation of the code for structs just above.
Tim.
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
--------------
2013 Aug 13
2
[LLVMdev] SimplifyLibCalls doesn't check TLI for LibFunc availability
Hi,
It looks like SimplifyLibCalls has a tendency to emit calls to libm functions without checking with TLI whether these calls are available.
For example, PowOpt has this code:
struct PowOpt : public UnsafeFPLibCallOptimization {
PowOpt(bool UnsafeFPShrink) : UnsafeFPLibCallOptimization(UnsafeFPShrink) {}
virtual Value *callOptimizer(Function *Callee, CallInst *CI, IRBuilder<> &B)
2017 Mar 15
2
Speculative execution of FP divide Instructions - Call-Graph Simplify
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 ],
2017 Mar 15
3
Speculative execution of FP divide Instructions - Call-Graph Simplify
[+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
2013 Aug 13
0
[LLVMdev] SimplifyLibCalls doesn't check TLI for LibFunc availability
On Tue, Aug 13, 2013 at 5:58 AM, Kuperstein, Michael M <
michael.m.kuperstein at intel.com> wrote:
> Hi,****
>
> ** **
>
> It looks like SimplifyLibCalls has a tendency to emit calls to libm
> functions without checking with TLI whether these calls are available.****
>
> For example, PowOpt has this code:****
>
> ** **
>
> struct PowOpt : public
2015 Jan 15
2
[LLVMdev] Handling of undef in the IR
Hi all,
I have a very simple test case (thanks to bugpoint) that hit an assert in reassociate.
(the assert is (C->getType()->isIntOrIntVectorTy() && "Cannot NEG a nonintegral value!"), function getNeg)
The function is taking a Constant as argument, but the assert does not expect an undef. I’m not sure whose responsibility is it to handle that (caller?).
Do we have to
2017 Mar 15
2
Speculative execution of FP divide Instructions - Call-Graph Simplify
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
2007 May 11
2
[LLVMdev] identifing mallocs with constant sizes
I am writing some code to identify malloc instructions with constant
request sizes and to determine the request size if it is constant. I
have two questions.
1) If a malloc is for an array allocation and the array size is a
ConstantExpr, how can I obtain the value of the ConstantExpr?
2) I am using the following logic to determine if the malloc is for a
constant request size and to
2019 Sep 26
2
ConstantFP->getType() is not right
Hi, I want to create a double constant from a float constant, here's my
code:
auto* constFloat1 =
static_cast<llvm::ConstantFP*>(llvm::ConstantFP::get(llvm::Type::getFloatTy(context),
3.1));
assert(constFloat1->getType() == llvm::Type::getFloatTy(context));
auto* constFloat2 =
llvm::ConstantFP::get(llvm::Type::getDoubleTy(context),
constFloat1->getValueAPF());
2008 Sep 25
3
[LLVMdev] Cannot Select ConstantFP on x86
I just ran into this today with x86-64:
Cannot yet select: 0x3cbc180: f64 = ConstantFP <1>
As far as I can tell, DAGCombiner comes along and sees an sint_to_fp of the
constant 1 and hapilly folds it into a ConstantFP<1>. ISel then blows up
because there's no pattern for it.
Does this look familiar to anyone? I don't see any relevant bugs in the
database.
2014 May 05
3
[LLVMdev] get unsigned integer pattern for ConstantFP
What is the proper way to get the bit pattern associated with a ConstantFP?
The 32 bit pattern if MVT::f32 or pair of 32 bit patterns with MVT::f64 ?
Tia.
Reed
2007 Sep 05
2
[LLVMdev] Seeing a crash with ConstantFP::get
Hola LLVMers,
I'm getting a crash when using ConstantFP::get.
I can repro it by adding one line to the Fibonacci example program:
int main(int argc, char **argv) {
int n = argc > 1 ? atol(argv[1]) : 24;
// Create some module to put our function into it.
Module *M = new Module("test");
// We are about to create the "fib" function:
Function