This is the mail archive of the gcc@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: RFC: target macro->hook migration idea


> I like your plan.  I'd thought about doing something similar for a
> long time, but I was always stuck on how to prevent half-migrations.
> You've got a scheme for that.

Well, a target could still be half-migrated, but it would still bear
the "not migrated" stigma.

We can work on the common-code migration over time; we should create
the poison conditional stuff when we're pretty much done.

* Migrate target.h and common code.
* Add -DPLEASE to all targets.
* Add the conditional poisoning.

> Now would be a great time to start on this.

The first step is to design the target structure.  We can add hooks to
the structure without using them, so we can start on this part "right
away" without needing to schedule migration time yet.

I've been using "calls" for call ABI related stuff (like
targetm.calls.return_in_memory()).  A brief look through the docs
suggests:

calls - Anything relating to calls - stack frame, arguments, returns,
	etc.

regs - register names, classes, modes, tiability, etc.  Reload and
	alloc too.

md - relating to how to deal with the MD file (predicates, ccmode, jump tables,
	most of the "misc" doc chapter)

mem - storage layout, types, endians, etc.

lang - hooks into the language front-ends (attributes, types, pragmas etc)

runtime - related to the run-time (libcalls, trampolines, crt0 and
	include-related)

debug - all debug hooks.  Might have debug.dwarf, debug.sdb,
	debug.stabs, etc.

opts - related to option (command-line) handling.


Or we could go with unabbreviated names ;-)


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