This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Tree SRA and atomicity/volatility
On 1/26/07, Mark Mitchell <mark@codesourcery.com> wrote:
Mike Stump wrote:
> On Jan 25, 2007, at 6:37 PM, Mark Mitchell wrote:
>> But, once you write it down, you get to figure out how to make sure that
>> the entire compiler honors it, including the machine-independent
>> TREE-SSA bits. Since the sensible choices may be different for each
>> CPU, how to enforce the right constraints (either separately for each
>> CPU, or some superset of all of them) may not be easy.
>
> Well, you know not writing it down doesn't absolve us from having to get
> it right anyway. I'd further say that writing it does should not
> constrain us from fixing the wording if the wording is broken, but I
> agree, if we write it down, it would be better to have the right
> theoretic answer and leave unspecified those bits that should be.
If we make promises and don't keep them, users might be angry. If we
don't make promises, they may be disappointed by the fuzziness, but at
least we're not tricking them.
I see that Ada _does_ make promises to the user. And I see the Ada
frontend tries to fulfill these promises by relying on the middle-end not
mucking up with TYPE_VOLATILE structs. (And to my surprise it
somehow works to some degree)
I'd like to have those bits that the middle-end can reasonably guarantee
specified - this will be a stricter better situation than what we have now.
I _don't_ suggest to put this anywhere in user documentation to suggest
we're promising anything on a C volatile struct type. But I want to nail
down as much as possible of the GCC frontend - middle-end interface.
As we happen to have (at least) one language that GCC supports that
has a somewhat strict and reasonable specification about a sort-of
volatileness we better make sure we can map this somehow to the
middle-end.
I'm in no way opposed to specifying exactly what "volatile" means on an
i686 CPU, but I think it's hard to specify and hard to implement. Prove
me wrong, by all means!
I would hope that we could all agree that (a) specifying the behavior in
detail would be nice, but (b) absent a specification, fixing issues on a
case-by-case basis is reasonable. It's a fallacy to argue that just
because I'm arguing for (b) that I'm opposed to a middle-end type
system, don't want to specify behavior.
I just want to make the compiler better, step by step, and the step
right in front of us is Eric's patch, which everyone agrees improves
things, modulo, perhaps, exactly how it's implement. So, let's get the
patch in, and move on. When someone wants to invest the effort in the
full specification, implementation, test cases, etc., we can do that,
but that shouldn't stop us fixing the current problem.
I disagree. We have a defect for Ada and Ada happens to require certain
semantics on a for now unspecified middle-end construct. It is perfectly
reasonable to require, that upon fixing this defect, the interface between
the frontend and middle-end is specified where it relates to that defect.
And I still request that the Ada folks come up with a sentence or two for
that. It would have been all done in the time we're discussing here.
Richard.