Btw, I think this is fine per se, but putting "__attribute__((acquire))"
on the functions that acquire a lock does seem to be problematic, in that
quite often you might well want to inline those things. How would you
handle that?
The fact is, the whole optimization is broken. You should never do
extraneous writes to anything but registers (or your own spill pool on the
stack - anything that hasn't had its address taken and cannot be visible
to outsiders). A C compiler should basically do what the user asks it to
do, and that means that it simply should be _very_ nervous about doing
optimizations that can have visible secondary effects.
So the first question that should be asked is: "is that optimization even
worth it in the first place outside of registers and the spill pool?"
If an optimization introduces visible behaviour differences to the
"obvious" stupid interpretation of the code, it should automatically be
something that should be given a lot of thought, and perhaps not enabled
at all by default (where "default" is certainly normal optimization
levels).
And different languages have different usages. In C, it's quite common
(and _possible_) for the programmer to specify how to do things at a
fairly low level. That's not true in all other languages, and it affects
how a compiler should optimize things. In C, a compiler should give more
weight to "this is how the user specified the solution" because in C,
programmers really *do* that.
So I don't think your proposal is wrong, but I think before even going to
something like that, you should ask yourself: "was that a valid
optimization to start with?"
(That said, there may well be *other* reasons for wanting gcc to know
about lock/unlock behaviour and teaching gcc about barriers. If gcc starts
getting more threading knowledge, gcc may well need to have that kind of
information in other places).
Linus
-
