[LLVMdev] [RFC] Scoped no-alias metadata
hfinkel at anl.gov
Mon Dec 3 11:49:54 PST 2012
----- Original Message -----
> From: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> To: llvmdev at cs.uiuc.edu
> Sent: Monday, December 3, 2012 1:30:31 PM
> Subject: Re: [LLVMdev] [RFC] Scoped no-alias metadata
> On 12/2/2012 2:48 PM, Hal Finkel wrote:
> > [...] As a result, we'll need to assign a unique identifier to each
> > lifetime region (roughly a block in C99, although this may be only
> > a partial block if a restrict pointer is declared in the middle of
> > the block).
> Whether restricted pointer is declared in the middle of a block or
> does not matter from the standard's perspective. Although I don't
> it changes much in your proposal (other than possibly eliminating
> difficult cases that could otherwise appear).
Yes, good, thank you. The rationale (which I just re-read a minute ago) also makes this clear:
"Cacheing the value in an object designated through
a restrict-qualified pointer is safe at the beginning of the block in which the
pointer is declared, because no pre-existing aliases may also be used to reference
that object. The cached value must be restored to the object by the end of the
block, where pre-existing aliases again become available."
This is convenient, but also makes 'restrict' somewhat unique: It retroactively imposes a restriction on code that comes before it. If feasible, we may want to come up with a good way to warn about this if the user is flagrantly violating it.
> "Let D be a declaration of an ordinary identifier that provides a
> of designating an object P as a restrict-qualified pointer to type T.
> If D appears inside a block and does not have storage class extern,
> B denote the block. If D appears in the list of parameter
> of a function definition, let B denote the associated block.
> let B denote the block of main (or the block of whatever function is
> called at program startup in a freestanding environment)."
> The above does not specify where in the block B, the declaration D
> appears. At the same time, the section below applies to the entire
> block B:
> "During each execution of B, let L be any lvalue that has &L based on
> If L is used to access the value of the object X that it designates,
> X is also modified (by any means), then the following requirements
> apply: T shall not be const-qualified. Every other lvalue used to
> the value of X shall also have its address based on P."
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev