[LLVMdev] [RFC] Invariants in LLVM
Hal Finkel
hfinkel at anl.gov
Sun Jul 20 11:56:55 PDT 2014
----- Original Message -----
> From: "Andrew Trick" <atrick at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Philip Reames" <listmail at philipreames.com>, "Chandler Carruth" <chandlerc at gmail.com>, "Richard Smith"
> <richard at metafoo.co.uk>, "Nick Lewycky" <nlewycky at google.com>, "LLVM Dev" <llvmdev at cs.uiuc.edu>
> Sent: Thursday, July 17, 2014 10:45:42 PM
> Subject: Re: [RFC] Invariants in LLVM
>
>
>
>
>
>
> 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
Alright, all votes have been for llvm.assume. Renaming in progress...
Thanks again,
Hal
>
>
> -Andy
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev
mailing list