Ian Lance Taylor schrieb:
Georg-Johann Lay <avr@xxxxxxxx> writes:
Several years ago -- before my time -- my company made a port for
Infineon TriCore. It works and is about to be SIL sertified. It uses a
similar ABI. I attached the patches. That are not very much changes,
but I don't like this kind of hacks and would prefer very much to keep
the frontend/middleend clean of backend issues.
That is an admirable goal, but in this case I think you are going to
have to change the middle-end to make your port work. I recommend that
you contribute the patches back to gcc mainline for the benefit of other
users. Of course this will require a copyright assignment or
disclaimer.
The small patch you sent looks quite reasonable.
I must admit that I don't like this bulk of micro-patches. They do not
solve the very problem (no prototypes for support functions), may
confuse some backends because TYPE is no more NULL_TREE for libfunc in
FUNCTION_ARG et al., are beyond the backend's sandbox, and I am not sure
if it fixes all combinations of target hooks/makros one can think of.
I am still waiting for my copyright assignment, maybe one day I will get
one... who knows.
For now I am simply using INIT_CUMULATIVE_ARGS
(INIT_CUMULATIVE_LIBCALL_ARGS would do as well) and reconstruct the
prototype from the function's name in libname rtx. As far as I can
depict from libfuncs.h, only "memmove", "memcpy", "memset" and "memcmp"
need to be reconstructed, maybe some parts of the non-local-goto/eh
stuff, too.
The implementation is redundant as is recreates information which is
present in some corner of the universe, but at least I need not touch
the middle-end to get working code :-)
What I do not know is wether or not some optimizations use the return
value of some support function in the case it is a pointer. What I can
say is that TARGET_FUNCTION_VALUE is not called for the suppot functions
I saw so far.
Georg-Johann
