[LLVMdev] [RFC] Scoped no-alias metadata

Hal Finkel 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
> not,
> does not matter from the standard's perspective.  Although I don't
> think
> it changes much in your proposal (other than possibly eliminating
> some
> 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. 

Thanks again,

> ---
> "Let D be a declaration of an ordinary identifier that provides a
> means
> 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,
> let
> B denote the block. If D appears in the list of parameter
> declarations
> of a function definition, let B denote the associated block.
> Otherwise,
> 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
> P.
> If L is used to access the value of the object X that it designates,
> and
> X is also modified (by any means), then the following requirements
> apply: T shall not be const-qualified. Every other lvalue used to
> access
> the value of X shall also have its address based on P."
> -Krzysztof
> --
> 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
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory

More information about the llvm-dev mailing list