I have looked at how other targest use the init_builtins/expand_builtins. Of course, I don't understand everything there but it seems indeed to be more for generating a series of instructions instead of a function call. I haven't seen anything resembling what I want to do.
I had also first thought of going directly in the define_expand and expanding to the function call I would want. The problem I have is that it is unclear to me how to handle (set-up) the arguments of the builtin_function I am trying to define. To go from no function call to : - Potentially spill output registers - Potentially spill scratch registers - Setup output registers with the operands - Perform function call - Copy return to output operand - Potentially restore scratch registers - Potentially restore output registers Seems a bit difficult to do at the define_expand level and might not generate good code. I guess I could potentially perform a pass in the tree representation to do what I am looking for but I am not sure that that is the best solution either. For the moment, I will continue looking at what you suggest and also see if my solution works. I see that, for example, the compiler will not always generate the call I need to change. Therefore, it does seem that I need another solution than the one I propose. I'm more and more considering a pass in the middle-end to get what I need. Do you think this is better? Thanks for your input, Jc On Tue, Sep 1, 2009 at 12:34 PM, Ian Lance Taylor<i...@google.com> wrote: > Jean Christophe Beyler <jean.christophe.bey...@gmail.com> writes: > >> I have been also been looking into how to generate a function call for >> certain operations. I've looked at various other targets for a similar >> problem/solution but have not seen anything. On my target >> architecture, we have certain optimized versions of the multiplication >> for example. >> >> I wanted to replace certain mutliplications with a function call. The >> solution I found was to do perform a FAIL on the define_expand of the >> multiplication for these cases. This forces the compiler to generate a >> function call to __multdi3. >> >> I then go in the define_expand of the function call and check the >> symbol_ref to see what function is called. I can then modify the call >> at that point. >> >> My question is: is this a good approach or is there another solution >> that you would use? > > I think that what you describe will work. I would probably generate a > call to a builtin function in the define_expand. Look for the way > targets use init_builtins and expand_builtin. Normally expand_builtin > expands to some target-specific RTL, but it can expand to a function > call too. > > Ian >
