This is the mail archive of the gcc-help@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: [BE] How to query attributes of a function being called?


Ian Lance Taylor schrieb:
Georg-Johann Lay <avr@gjlay.de> writes:

Hi, proplems arise here:

struct S
{
    void (*foo)(void);
    void (*cb)(void) __attribute__((callback));
};

void caller (struct S s, struct S *ps)
{
    s.cb();    // #1
    ps->cb();  // #2
}

Call #2 seems to work, REG_EXPR yiels a COMPONENT_REF.

But for call #1 REG_EXP is NULL_TREE in final, and so is the
corresponding MEM_EXPR of the enclosing MEM.

So the middle-end nullifies all informations about the callee or never
makes an effort to get it.

The middleend is an ocean of information, but hardly a drop of water
reaches the desert of the backend... :-(

In some cases, call #1 gives a non-NULL_TREE REG_EXPR, but it then is
a PARM_DECL and you do knot know which component is the one that is
being called.

You're right, I wouldn't expect a case like this to work, as there is no convenient tree for the RTL to refer to. If you need it to work, then I think you will need to somehow annotate the call rtx itself. There is no existing mechanism for carrying general function call attributes through to RTL.

I'm not 100% sure that for this kind of case that attribute will always
survive in GIMPLE, either.  I could easily imagine code like this:
    s.cb();
    s.cb();
being turned into
    temp = s.b;
    (*temp)();
    (*temp)();
and in that case the attribute might be lost.

I'm not certain that you can do this completely reliably without
frontend changes.

Ok, would have been nice to use __attribute__, but it obviously does not cover all cases and has not a stringent semantic. So I will have to use an other technique which is not as comfortable as attributes for the user.


I think qualifiers would do, but unfortunately there is no way to add machine specific qualifiers in the backend, and hacking gcc is not feasable in a reasonable amount of time. (Just imagine you'd like to have 'near', 'far', 'huge' pointers and would have to review and fix every usage of Pmode!)

Many thanks for your helpful hints!

Georg-Johann


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