[Bug c/48885] missed optimization with restrict qualifier?
glisse at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Wed Oct 16 11:36:00 GMT 2013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48885
--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Paulo J. Matos from comment #5)
> I would love to say I am convinced but I am not [yet].
Note that interpreting the standard and deciding what to implement in gcc are
very different and almost independent problems. The "one restrict is enough"
version seems harder to implement: you need to prove that a pointer is not
based on another one, whereas with "all pointers restrict" you can just check
that they come from different declarations.
> Extern seems to have
> special meaning given the sentence from the standard:
> "2 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)."
That's just trying to define the scope where the non-aliasing rule applies, but
the rule itself remains the same.
> My initial comments were based on this explanation:
> http://cellperformance.beyond3d.com/articles/2006/05/demystifying-the-
> restrict-keyword.html
>
> First I do understand this is not the standard but it sounded much clear:
> "In this case, I promise that the pointer declared along with the restrict
> qualifier is not aliased. I certify that writes through this pointer will
> not effect the values read through any other pointer available in the same
> context which is also declared as restricted."
The "which is also declared as restricted" part is an invention. See my quote
from the C99/C11 standard: "Every other lvalue", not just those based on a
restrict pointer.
See also the early statement of intent: "An object that is accessed through a
restrict-qualified pointer has a special association with that pointer. This
association, defined in 6.7.3.1 below, requires that all accesses to that
object use, directly or indirectly, the value of that particular pointer." and
associated footnote: "For example, a statement that assigns a value returned by
malloc to a single pointer establishes this association between the allocated
object and the pointer."
When you call malloc, you know this memory aliases nothing, so you can mark it
so, you don't have to (and it would obviously be wrong) mark all the other
pointers as restrict to say so.
More information about the Gcc-bugs
mailing list