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: sh64-elf (SH5) port


On Feb  3, 2002, Mark Mitchell <mark@codesourcery.com> wrote:

>> +#define CANNOT_MODIFY_JUMPS \
>> +  (TARGET_SHMEDIA && (reload_in_progress || reload_completed))

> This doesn't conform to our new target methodology.  This should be
> a callback in the target structure, and then you don't need any
> #ifdef's elsewhere.

Ok, I'll do that, even though it is my hope that this macro eventually
goes away.  Ideally, we've have all of the cfg reorg infrastructure
capable of coping with the inability to redirect a branch (i.e.,
gen_jump returning NULL), and having some additional interfaces to
redirect jumps, as opposed to creating new ones and deleting the
original ones as we sometimes do now.  It may require information
about register liveness, particularly on this target.

>> +		&& ! MS_BITFIELD_LAYOUT_P (t)
>> +#endif

> Similarly, we should just always define the macro/callback, but make
> it return zero on most targets.

With a preference for a callback, I suppose.

You know...  For some reason, I strongly dislike this approach of
structures with callbacks.  As clean as it may look, it makes it way
more difficult to introduce a new entry point, and it makes it
insanely for difficult to define a md-specific entry point in such a
way that it depends on information only available at run time.

To wit, see the ugliness of the clean up code I had to introduce in
OVERRIDE_OPTIONS to tell GCC that the sh-elf assembler does not
support `.quad':

    {									\
       /* Only the sh64-elf assembler fully supports .quad properly.  */\
       targetm.asm_out.aligned_op.di = NULL;				\
       targetm.asm_out.unaligned_op.di = NULL;				\
    }									\


If I had to introduce similar junk to get things working cleanly on SH
just because there's a lot of stuff that depends on TARGET_SH5 or
TARGET_SHMEDIA, the port would have been far *more* complicated, not
simpler.

I understand that the goal is to eventually make the compiler
retargetable by means of replacing the global variable targetm, but by
making it a global variable, instead of a global pointer, and writing
a lot of code that assumes that targetm is a global variable, it
appears to me that we're doing it exactly the wrong way.  If it were a
pointer, and we treated it as such, we'd be able to retarget the
compiler by simply modifying the pointer.  The way we're coding it
now, every port defines a targetm variable, such that their .c files
can't be linked together, and targetm is always accessed as a struct,
so, should we turn them into pointers, we'd need an IMHO ugly #define
targetm (*targetm_p).  Perhaps I'm just missing part of the big
picture?


Anyway, I'll make the changes to follow the new standards, as much as
I might dislike them.  However, this will increase the amount of
common code touched, which is exactly what you had asked me to
minimize, so I hope this artificial increase won't make the patch
unacceptable.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer


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