This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-profiling] fix some side corners of finalization machinery




Jan Hubicka wrote:

While I agree with you at the top level. There is a problem with perspective with these definitions.

{function body|name} {visible | invisible}

with respect to the bodies, the idea is visible from inside the compilation unit.
with respect to the names, the idea is visible from outside the compilation unit.



I have problems to follow you here. We do have multiple concepths to visibility - we have visibility of body to the IPA optimizers (ie I know that the body is this one so I will optimize) and we do have the visibility from linker point of view (ie this function can be referenced from elsewhere or not). These are kind of ortoghonal. What about calling the first one availability? I have cgraph_body_available returining "AVAILABLE/OVERWRITTABLE/NOT_AVAILABLE" enum?

For the other visibility I think the current scheme
(TREE_PUBLIC/TREE_STATIC flags) work mostly OK if the
cgraph_body_available takes care of the varying emantics of local
binding...


My problems were with nomenclature, not with meaning. Calling one available and the other on visible is the right solution.

There is also something that I have not bitten off yet. That is what about the standard libraries. Apparently I can know a lot more about the function bodies of some of these without actually having the body around. There are currently some attributes that are processed (i.e. hidden) for a lot of the math library where I can know that the only side effect that this function could have is that errno is modified. I say hidden because it looks like the compiler has a flag that either marks these functions as pure if errno is not set but if the flag goes the other way provides no information about about the function.

I could do a lot better with these functions if I could see the unvarnished flags because from my point of view all statics can live across the call with the possible exception of errno (depending on the flag).



You can easilly figure out if the function is constant or pure. You can you use the call_expr_flags when inspecting the function.

Also note that GCC has code that discovers the fact that function is
const or pure on RTL level.  This can probably be something your
aliasing code can do more easilly (with combination of the cfg inliner
patch as we need to prove that the function is not infinite before
marking it so)



I understand this, however, there are a lot of attributes that can be either attached to the function by the programmer or are just known to the compiler for the standard libraries. What I was complaining about is that these need to be further thought thru since it is clear that they do not provide the best information with repect to register allocation and clobbering.

Honza




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]