[LLVMdev] [RFC] Invariants in LLVM

[Andrew Trick]

> On Jul 17, 2014, at 8:19 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> ----- Original Message -----
>> From: "Philip Reames" <listmail at philipreames.com>
>> To: "Hal Finkel" <hfinkel at anl.gov>, "LLVM Dev" <llvmdev at cs.uiuc.edu>
>> Cc: "Chandler Carruth" <chandlerc at gmail.com>, "Andrew Trick" <atrick at apple.com>, "Richard Smith"
>> <richard at metafoo.co.uk>, "Nick Lewycky" <nlewycky at google.com>
>> Sent: Thursday, July 17, 2014 4:31:10 PM
>> Subject: Re: [RFC] Invariants in LLVM
>> 
>> 
>> On 07/17/2014 01:39 PM, Hal Finkel wrote:
>>> Hello everyone,
>>> 
>>> I'm starting a new thread, as a follow-up to several older ones, on
>>> invariants in LLVM. Fundamentally, invariants are conditions that
>>> the optimizer is allowed to assume will be valid during the
>>> execution of the program. Many other compilers support a concept
>>> like this, MSVC's __assume, for example. GCC has a builtin called
>>> __builtin_assume_aligned which also neatly falls into this class.
>> First of all, thank you for working on this!  I'm thrilled to see
>> progress being made here.
>>> 
>>> In my initial patches, I've named the associated IR-level intrinsic
>>> @llvm.invariant(i1) (maybe it should be @llvm.assume, etc. --
>>> please feel free to express an opinion).
>> My bikeshed preference would be "assume".  "invariant" makes me think
>> "loop invariant" - i.e. something which needs to be proven. "assume"
>> is
>> a traditional name (in the verification world) for something which
>> can
>> be assumed true without verification and can result in invalid
>> results
>> if actually untrue.
> 
> That's two votes for 'assume' (you and Chandler from his code review); anyone else?

+1

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140717/6793746b/attachment.html>