search for: semantics

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 singl...

...rty of the function or call site being analyzed. Duncan mentioned that doesNotThrow is actually an important language semantic meaning that an unwind calls a language-defined behaviour such as calling terminate(). What happens in other languages? Chris and I also couldn't agree on what the semantics ought to be going forward. He suggested having two bits, one to memoize an analysis proving that it can't unwind, and one to mean that an unwind triggers terminate. I happen to think that this ought to be explicitly modelled in the IR by arcing to another BB that calls terminate. We do agr...

...all site being analyzed. Duncan mentioned that doesNotThrow is actually > an important language semantic meaning that an unwind calls a > language-defined behaviour such as calling terminate(). What happens in > other languages? > > Chris and I also couldn't agree on what the semantics ought to be going > forward. He suggested having two bits, one to memoize an analysis > proving that it can't unwind, and one to mean that an unwind triggers > terminate. I happen to think that this ought to be explicitly modelled > in the IR by arcing to another BB that calls t...

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 of the result is undef." We found this semantics to be problematic. TL;DR: instru...

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,

...: 27 de novembro de 2019 01:10 To: Nuno Lopes <nuno.lopes at ist.utl.pt>; LLVMdev <llvm-dev at lists.llvm.org> Cc: spatel at rotateright.com; Juneyoung Lee <juneyoung.lee at sf.snu.ac.kr>; zhengyang-liu at hotmail.com; John Regehr <regehr at cs.utah.edu> Subject: RE: LangRef semantics for shufflevector with undef mask is incorrect The shuffle mask of a shufflevector is special: it's required to be a constant in a specific form. From LangRef: "The shuffle mask operand is required to be a constant vector with either constant integer or undef values." So really, we...

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 attributes like dereferenceable. I fou...

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

...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 of semantics is an LLVM property that applies to all front ends, but the front ends will have to do something to initialize them. I will eventually do something to convert this into an RST document and find a home for it in the clang documentation, but I'd like to start by getting input on whether everyone...

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 >...

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. Sounds logical! But what is the discussion about then? Ciao, Duncan.

...ounds reasonable to me overall. There are some CMake issue to go through (I need to dig into it a bit). When I run `ninja check-flang` at the moment (after fixing CMake) I end up with: Testing Time: 16.22s ******************** Failing Tests (12): Flang :: Lower/pre-fir-tree04.f90 Flang :: Semantics/allocate11.f90 Flang :: Semantics/allocate13.f90 Flang :: Semantics/c_f_pointer.f90 Flang :: Semantics/call04.f90 Flang :: Semantics/canondo16.f90 Flang :: Semantics/coarrays01.f90 Flang :: Semantics/critical02.f90 Flang :: Semantics/doconcurrent01.f90 Flang :: Seman...

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. > Chris and I also cou...

....variable.length.store.<br>We have implemented the infrastructure for defining and lowering these in this phabricator patch: <a href="https://reviews.llvm.org/D86693" >https://reviews.llvm.org/D86693</a></div> <div> </div> <div>These represent the semantics of loading and storing a variable number of bytes to a fixed-width register;<br>in effect, a masked load or store where the only active lanes are given by a contiguous block.</div> <div> </div> <div>There are a few reasons for separately representing this kind of opera...

...ing at this a bit, it really seems like this flag has the exact same meaning as !invariant.load. > > pointsToConstantMemory returns a value for a Location. Since it is entirely legal to have two Locations which describe the same physical memory, it seems like you'd be back to the same semantics as !invariant.load. > > The only uncertainty here is that a Location is clearly (??) position/Instruction specific. Does that also imply that the Location is control dependent? What is the semantics of the following code? > if (is_known_invariant) { > load %p, !tbaa is_constant=t...

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 Undefined..." PLDI paper, which seemed like a nice writeup. I'd like to formalize this in a theorem prover or Cryptol. Sin...

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 eq i1 %tmp1001,...

...dated by the caller. Conversion from decimal is not currently implemented. Four formats are built-in: IEEE single precision, double precision, quadruple precision, and x87 80-bit extended double (when operating with full extended precision). Adding a new format that obeys IEEE semantics only requires adding two lines of code: a declaration and definition of the format. All operations return the status of that operation as an exception bit-mask, so multiple operations can be done consecutively with their results or-ed together. The returned status can be useful...

...dig into it a bit). > > > > When I run `ninja check-flang` at the moment (after fixing CMake) I end up > with: > > > > Testing Time: 16.22s > > ******************** > > Failing Tests (12): > > Flang :: Lower/pre-fir-tree04.f90 > > Flang :: Semantics/allocate11.f90 > > Flang :: Semantics/allocate13.f90 > > Flang :: Semantics/c_f_pointer.f90 > > Flang :: Semantics/call04.f90 > > Flang :: Semantics/canondo16.f90 > > Flang :: Semantics/coarrays01.f90 > > Flang :: Semantics/critical02.f90...