similar to: [LLVMdev] Related constant folding of floating point values

Hi Arsen, On Oct 9, 2013, at 4:53 AM, Arsen Hakobyan <artinetstudio at gmail.com> wrote: > Hi all, > > I have the following test case: > #define FLT_EPSILON 1.19209290E-7 > > int err = -1; > int main() > { > float a = 8.1; > if (((a - 8.1) >= FLT_EPSILON) || ((a - 8.1) <= -FLT_EPSILON)) { //I am > using FLT_EPSILON to check whether (a != 2.0).

On Thu, Sep 08, 2011 at 11:15:06AM -0500, Villmow, Micah wrote: > Peter, > Is there a way to make this flag globally available? Metadata can be fairly expensive to handle at each node when in many cases it is a global flag and not a per operation flag. There are two main reasons why I think we shouldn't go for global flags: 1) It becomes difficult if not impossible to correctly link

Hi all, I want to generate an assembly instruction for my target using target description representation of the instruction. The problem is that I want to add direct register to be chose as an output register for my target. Does it possible to do with an instruction definition in TARGETInstrInfo.td file? May be someone could help with an example? Currently I have seen that we can pass the name

For the following C code __fp16 x, y, z, w; void foo() { x = y + z; x = x + w; } clang produces IR that extends each operand to float and then truncates to half before assigning to x. Like this define dso_local void @foo() #0 !dbg !18 { %1 = load half, half* @y, align 2, !dbg !21 %2 = fpext half %1 to float, !dbg !21 %3 = load half, half* @z, align 2, !dbg !22 %4 = fpext half %3 to float, !dbg

Thanks Eli. I forgot to bring up the strict FP questions which I was working on when I found this. If we're in a strict FP function, do the fp_to_f16/f16_to_fp emitted by promoting load/store/bitcast need to be strict versions of fp_to_f16/f16_to_fp. And if so where do we get the chain, especially for the bitcast case which isn't a chained node. ~Craig On Tue, Dec 10, 2019 at 3:18 PM

On Jul 14, 2014, at 7:23 AM, Tom Stellard <tom at stellard.net> wrote: > On Mon, Jul 14, 2014 at 01:08:54PM +0100, Tim Northover wrote: >> Hi all, >> >> What do people think of doing away with the @llvm.convert.to.fp16 and >> @llvm.convert.from.fp16 intrinsics, in favour of using "half" and >> fpext/fptrunc? [1] >> > > I am in favor

I have a simple test case that my code generator handles fine when using optimizations, but when I disable optimizations, It turns into a sequence of instructions that I can't figure out what to setup to get it to generate the correct code. The instructions in question are: %tmp1 = load float* %test ; <float> [#uses=1] %conv = fpext float %tmp1 to double ;

The sign information for binary operators is available in the llvm IR by the 'nsw' (no signed wrap) flag. Seems there is no use of this flag in the code generation phase. The sign information is no more available in the selection DAG. So how can I generate different instructions for binary operators with signed/unsigned operands in the assembler (e.g. mul/mulu)? -- View this message in

Hello I want to transfer value (Value* src) of the type `FloatTyID` to `DoubleTyID`(I need all floats to be saved as 8 bytes).I have tried: builder.CreateCast(llvm::Instruction::FPExt, src, llvm::Type::getDoubleTy(llvmContext),””) I don`t know if I use CreateCast correctly and if this approach is correct at all. Thank you. Yakov -------------- next part -------------- An HTML attachment

Hi, LLVM community: I found basicaa seems not to tell must-not-alias for __restrict__ arguments in c/c++. It only compares two pointers and the underlying objects they point to. I wonder how clang does alias analysis for c/c++ keyword restrict. let assume we compile the following code: $cat myalias.cc float foo(float * __restrict__ v0, float * __restrict__ v1, float * __restrict__ v2, float *

It doesnt work it fails with assertation that cast is invalid .What could be done? On 11/14/11, Duncan Sands <baldrick at free.fr> wrote: > Hi Yakov, that looks correct to me. You can also use CreateFPExt which is > slightly simpler. > > Ciao, Duncan. > > >> I want to transfer value (Value* src) of the type `FloatTyID` to >> `DoubleTyID`(I >> need all

Hi all, What do people think of doing away with the @llvm.convert.to.fp16 and @llvm.convert.from.fp16 intrinsics, in favour of using "half" and fpext/fptrunc? [1] It looks like those intrinsics originally date from before "half" actually existed in LLVM, and of course the backends have grown up assuming that's what Clang will produce, so we'd have to improve their

Hi, Your problem is that the function arguments, which are makes as noalias, are not being directly used as the base objects of the array accesses: > %v0.addr = alloca float*, align 8 > %v1.addr = alloca float*, align 8 > %v2.addr = alloca float*, align 8 > %t.addr = alloca float*, align 8 ... > store float* %v0, float** %v0.addr, align 8 > store float* %v1, float** %v1.addr,

Peter, Is there a way to make this flag globally available? Metadata can be fairly expensive to handle at each node when in many cases it is a global flag and not a per operation flag. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Robert Quill > Sent: Thursday, September 08, 2011 3:24 AM > To: Peter

[This is something like a bug report; maybe somewhat longish & technical ..] As an introduction, just try the following code (it should work both in R and S). I think it screws up the postscript() driver both for S and R, but this is not the issue here. is.R <- function() { ## returns 'TRUE' iff we are using 'R' exists("version") && !is.null(vl

On Mon, Jul 21, 2008 at 1:21 PM, Stefanus Du Toit <stefanus.dutoit at rapidmind.com> wrote: > 1) Vector shl, lshr, ashr > > I think these are no-brainers. We would like to extend the semantics > of the shifting instructions to naturally apply to vectors as well. > One issue is that these operations often only support a single shift > amount for an entire vector. I assume it

The problem seems that ":" always coerces to integer, but should not.. 9.9:12 ## R: [1] 9 10 11 ## S-plus 3.4: [1] 9.9 10.9 11.9 ## and many more examples.... -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or

I sure that is.What could be other reasons for such error? Yakov On Mon, Nov 14, 2011 at 5:44 PM, Duncan Sands <baldrick at free.fr> wrote: > On 14/11/11 16:39, Yakov Malinkovich wrote: > >> It doesnt work it fails with assertation that cast is invalid .What >> could be done? >> > > Maybe src doesn't have Float type? > > Ciao, Duncan. > > >

Hi Arsen, we are beyond what I understand about how metadata operates. Maybe Adrian or David knows. --paulr From: Arsen Hakobyan [mailto:hakobyan.ars at gmail.com] Sent: Friday, January 12, 2018 12:16 PM To: Robinson, Paul Cc: llvm-dev at lists.llvm.org; David Blaikie Subject: Re: [llvm-dev] StripDeadDebugInfo for static inline functions. Just one update: the function causing the segmentation

+ Adrian + David Hi Arsen, This sounds like a bug to me. Have you tried reproducing it on trunk? For instance, I see that the relation between DICompileUnit and DISubprogram was changed in the meantime (https://reviews.llvm.org/D19034 <https://reviews.llvm.org/D19034>). If this no longer occurs on master you could bisect the compiler to find the commit(s) that fix this and consider