similar to: Safe fptoui/fptosi casts

I would be interested in learning what the set of used semantics for float-to-int conversion is. If the only two used are 1) undefined behavior if unrepresentable and 2) saturate to int_{min,max} with NaN going to zero, then I think it makes sense to expose both of those natively in the IR. If the set is much larger, I think separate intrinsics for each behavior would make sense. It would be nice

Hi Joe & Michael, In rev. 151382 you have changed the fptoui implementation of the x86 codegen for win32. Before the change fptoui was lowered to flds 16(%esp) fisttpll 8(%esp) movl 8(%esp), %eax After the change fptoui is lowered to flds 40(%esp) calll _ftol2 Please note that the assumption that _ftol2 doesn't modify ECX isn't true on sandybridge platform.

Hi, I have some IR module from random generation (mostly ineffective instructions). It has a function with void return, and two function arguments where one is a reference. Therefore, I expect every instruction not altering the value at the 2nd arguments address should be ineffective. Here is the function definition (see below for full ll): define void @_Z27entityMainDataInputCallbackdRd(double

On Fri, Jan 20, 2012 at 2:10 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > X86FloatingPoint.cpp with comments is all you get. Thanks for your help, Jakob. Attached is a first-pass attempt at a patch. I don't want to post to -commits yet because I have no idea if this is fully correct, but it seems to work in simple test cases. Am I on the right track? Could this patch ever

Hi, Lately we have come to realize how undef makes our life complicated.. Therefore in this email we propose to change the behavior of a few instruction to yield poison instead of undef in error cases. This follows the suggestion of Eli in https://reviews.llvm.org/D33654. Why is undef so bad? - I believe it's not possible to make newgvn correct with undef. See for example the discussion

On Jan 20, 2012, at 1:58 PM, Joe Groff wrote: > The integer runtime functions (_allmul, _alldiv, etc. for 64-bit > integer arithmetic) all appear to be straight-up stdcall. _ftol2 is > the only weird one. (There is an _ftol routine with the same calling > convention as _ftol2, but AFAIK it's only for backward compatibility > with older MSVC runtimes.) I'm far from an MSVC

[+CC Andy] Hi Elena, I don't have any fundamental issues with teaching SCEV about floating point types, but given this will be a major change, I think a high level roadmap should be discussed on llvm-dev before we start reviewing and committing changes. Here are some issues that I think are worth discussing: - Core motivation: why do we even care about optimizing floating point

Hi all, Consider the following snippet, the aim of which is to convert a double to a signed i16, returning 0 if not exactly representable: define i16 @foo(double) { top: %1 = fptosi double %0 to i16 %2 = sitofp i16 %1 to double %3 = fcmp une double %2, %0 %4 = select i1 %3, i16 0, i16 %1 ret i16 %4 } Of course, if the value is out-of-range, the result of fptosi is undefined.

On 01/08/2018 07:06 PM, Richard Smith via llvm-dev wrote: > On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi Kevin, > > Thanks for reaching out about this, and thanks especially for > offering to help. I've had some other priorities that have > prevented

Hello, I want to call a function "fx" given by name, where some "global" variables (in the environment of fx) are passed to the function. For compatibility reasons I cannot modify the parameter list of fx and I want to avoid setting variables in the global environment (e.g. via <<-) Is there a way, how to do this? Thomas P. The example: fx <- function(y)

On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kevin, > > Thanks for reaching out about this, and thanks especially for offering to > help. I've had some other priorities that have prevented me from making > progress on this recently. > > As far as I know, there is no support at all in clang for handling the >

Hello llvm-dev, I'm working on a project that is looking at using BPF as the underlying instruction set for running programs in a protected environment. We have a working prototype but have run into a few issues and missing functionality. It appears these might be due to BPF development being focused on usage in the Linux kernel. Our requirements are broader (rodata, shared objects with

Hi Kevin, Thanks for reaching out about this, and thanks especially for offering to help. I've had some other priorities that have prevented me from making progress on this recently. As far as I know, there is no support at all in clang for handling the FENV_ACCESS pragma. I have a sample patch somewhere that I created to demonstrate how the front end would create the constrained intrinsics

I have encountered a need for float-to-int casts that saturate to min/max when the value is out of the range of the target type. It seems that there is no intrinsic to do this, currently, but on IRC it was pointed out that a patch [1] has been proposed to implement this functionality in exactly the way that I was looking for. It looks like the discussion has died out but I was hoping maybe to

wasm-ld is currently unable to link a shared wasm library (generated with `wasm-ld --shared`) with .o files and produce a working executable. I'm curious if there's a fundamental reason for this, or is this simply something that wasn't needed and could be implemented if needed. I think this could be done by - Resolving "GOT.mem" and "GOT.func" imports and

I am a little confused by the results of the result of fptoui ... seems to conflict with the instructions semantics as defined in the language reference (http://llvm.org/docs/LangRef.html#i_fptoui): %tmp1001 = fptoui float 1.0E+300 to i1 ; % yields tmp1001 = 0 on my machine! but the ref says: %Y = fptoui float 1.0E+300 to i1 ; yields i1:true (checked the return value with ... icmp

Is there any reason to expect a problem ? i'm running this script on the cluster down the hall: module load R/2.11.0 R library(multicore) fxx<-function(ll) runif(1) mclapply(1:10,fxx) i get: Error in fork() : Unable to fork. less /proc/cpuinfo yields: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU

On Jan 24, 2012, at 2:30 PM, Joe Groff wrote: > On Fri, Jan 20, 2012 at 2:10 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: >> X86FloatingPoint.cpp with comments is all you get. > > Thanks for your help, Jakob. Attached is a first-pass attempt at a > patch. I don't want to post to -commits yet because I have no idea if > this is fully correct, but it seems

On 8 Jan 2018 19:50, "Hal Finkel via cfe-dev" <cfe-dev at lists.llvm.org> wrote: On 01/08/2018 07:06 PM, Richard Smith via llvm-dev wrote: On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kevin, > > Thanks for reaching out about this, and thanks especially for offering to > help. I've had some other

Hi, the function outer can not apply a constant function as in the last line of the following example: > xg <- 1:4 > yg <- 1:4 > fxyg <- outer(xg, yg, function(x,y) x*y) > fconstg <- outer(xg, yg, function(x,y) 1.0) Error in outer(xg, yg, function(x, y) 1) : dims [product 16] do not match the length of object [1] Of course there are simpler ways to construct a constant