search for: semantical

Dear LLVMdev, We have a question regarding the semantics of the undefined value in LLVM IR. As far as we understand, in order to give a semantics to the undefined value, the semantics of LLVM IR is generalized to a rather unusual set-based semantics. More specifically, the notion of value in LLVM IR is generalized to a set of values, rather than a single value. Then the undefined value is simply

Hi everyone, Since I'm busy muddying the waters by changing how exception handling works, I thought I should ask for clarification on the exact behaviour of the current 'nounwind' attribute found on functions, calls and invokes. I was thinking these would be similar to the AA analysis notes like "doesNotAccessMemory" which is a provable property of the function or call

Hi Nick, > Since I'm busy muddying the waters by changing how exception handling > works, I thought I should ask for clarification on the exact behaviour > of the current 'nounwind' attribute found on functions, calls and invokes. > > I was thinking these would be similar to the AA analysis notes like > "doesNotAccessMemory" which is a provable property

Hi, This is a follow up on a discussion around shufflevector with undef mask in https://reviews.llvm.org/D70641 and https://bugs.llvm.org/show_bug.cgi?id=43958. The current semantics of shufflevector in http://llvm.org/docs/LangRef.html#shufflevector-instruction states: "If the shuffle mask is undef, the result vector is undef. If any element of the mask operand is undef, that element

Hi all, In light of recent discussions regarding updating passes to respect convergent semantics, and whether or not it is sufficient for barriers, I would like to propose a change in convergent semantics that should resolve a lot of the identified problems regarding loop unrolling, loop unswitching, etc. Credit to John McCall for talking this over with me and seeding the core ideas. Today,

Can we go back a little? 1) Add a new transformation to InstCombine that will replace 'getelementptr > i8, i8* null, <ty> %n' with 'inttoptr <ty> %n to i8*' when <ty> has the > same size as a pointer for the target architecture. What's the actual problem with this approach? I personally find it the most compelling - it is well-defined (well,

Ok, makes sense. My suggestion is that we patch the IR Verifier to ensure that the mask is indeed a vector of constants and/or undefs. Right now it only runs the standard checks for instructions. We will also run Alive2 on the test suite to make sure undef is never replaced in practice. Thanks, Nuno -----Original Message----- From: Eli Friedman <efriedma at quicinc.com> Sent: 27 de

Hello all, LangRef says it is undefined behavior to pass null to a nonnull argument (`call f(nonnull null);`), but the semantics is too strong for a few existing optimizations. To support these, we can relax the semantics so `f(nonnull null)` is equivalent to `f(poison)`, but (A) it again blocks another set of optimizations, and (B) this makes the semantics of nonnull deviate from other

Hello LLVM fathers, 1. "languages, semantic trees" what do you think ideally, do languages implementations based on LLVM need internal semantic tree or they should rather try to use LLVM directly in/after syntax parsing? For languages like C++ the expected answer is "of course we need an internal semantic tree between parsing and LLVM!" But I am still

Hi all, I'm trying to put together a set of rules for how the various floating point semantic modes should be handled in clang. A lot of this information will be relevant to other front ends, but the details are necessarily bound to a front end implementation so I'm framing the discussion here in terms of clang. Other front ends can choose to follow clang or not. The existence of this set

Hey guys, I am wondering what the semantics for fdiv is, if the denominator is zero. For sdiv, the language reference specifies that this is undefined behavior. For fdiv, the language reference says nothing (hence, I assume that it is defined somehow). So how is it defined? Does it follow IEEE-754 definition, i.e., +Inf if nominator is > 0, -Inf if nominator is < 0, otherwise NaN?

On Tuesday 27 January 2009 20:56:30 Mike Stump wrote: > On Jan 27, 2009, at 8:42 PM, Duncan Sands wrote: > > one thing that seems to be clear to everyone except me is... what > > are the > > semantics supposed to be? > > I don't know of any other semantic other than, if they are supposed to > be in the same register, then they have to be in the same register.

Hi Mehdi, I can't replicate those failures at my end, could you let me know what OS, compiler and CMake flags you're using so I can try and reproduce? Thanks! David Truby ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> Sent: 07 April 2020 06:44 To: Richard Barton

Hi, as a language front end developer I am a bit terrified by any "unwind here will call terminate" semantics in the IR. I'd prefer the LLVM IR to be free from any assumptions about the languages compiled to it and this looks like C++ semantics sneaking into LLVM. Thus I'm under the expression the calling terminate semantics should be implemented by the front end.

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:10pt" ><div dir="ltr" ><div>We propose introducing two new intrinsics: llvm.variable.length.load and llvm.variable.length.store.<br>We have implemented the infrastructure for defining and lowering these in this phabricator patch: <a

> On Dec 1, 2014, at 3:44 PM, Philip Reames <listmail at philipreames.com> wrote: > > (Spawning a separate subthread off the 'Optimization hints for "constant" loads' discussion for a related question. ) > > Looking at TBAA again, I was reminded that TBAA also contains a third field which indicates that "meaning pointsToConstantMemory should return

Hi, I'm new to the LLVM mailing list, but I've been working on tools for symbolic execution/formal modeling of LLVM off and on for a while. I’m trying to understand the current status of the LLVM undef/poison semantics from a frontend/verification perspective. I saw there was a lot of interest in a proposed semantics in late 2016 and mid-2017. Perhaps this was due to the “Taming

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

This patch supplies software IEEE floating point support. The comment from the patch reproduced below says all there is to say. This patch contains the prior "cleanup" patch; please don't apply that one. Please let me know of any bugs. It is tested reasonably well, but until I put together random tests it's hard to have 100% confidence. Neil. /* A self-contained host- and

Attached is the log. I'm building with: clang version 10.0.0 (https://github.com/llvm/llvm-project/ 3a6da1122b990386edeba0987d0d1fdc9c8dc53d) Target: x86_64-unknown-linux-gnu Thread model: posix On some Ubuntu-like distribution. I also ran with ASAN once and it found a bunch of leaks in bin/tco. Best, -- Mehdi On Tue, Apr 7, 2020 at 4:36 AM Richard Barton <Richard.Barton at