This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Fix other/44566
Quoting Steven Bosscher <stevenb.gcc@gmail.com>:
Also in a single file? i.e.
Yes, I've put this into 2f.c and compiled with -O2:
.file "2f.c"
.section ".text"
.align 2
.globl foo_default_arch
.type foo_default_arch, @function
foo_default_arch:
li 3,42
blr
.size foo_default_arch, .-foo_default_arch
.arch "spu-elf"
.text
.align 2
.align 3
.global foo_spu
.type foo_spu, @function
foo_spu:
il $3,42
bi $lr
.size foo_spu, .-foo_spu
.ident "GCC: (GNU) 4.6.0 20100625 (experimental)"
Note, there is a target hooks for the architecture switch of the output,
so if you want, you can put the output in separate files instead.
Re. documentation: I didn't find any place where it is described what
should be wrapped in START_TARGET_SPECIFIC / END_TARGET_SPECIFIC. This
is important because if people don't know what to mark then new
target-specific things end up not put in the target-specific name
space. It is not obvious to me what is to be marked.
OK, we can do a bit of Q&A to get some material for our documentation.
For example:
* why are create_mem_ref, addr_for_mem_ref, and maybe_fold_tmr wrapped
in START/END_TARGET_SPECIFIC in tree-flow.h, but tree_create_mem_ref
and get_address_description not?
As a general rule, if a function uses a target specific variable or macro,
or another function which is itself target specific, it too is target
specific.
create_mem_ref uses sizetype and create_mem_ref_raw. We could get the
right sizetype from the target vector, but create_mem_ref_raw uses
valid_mem_ref_p, which is intrinsically target specific.
addr_for_mem_ref uses LAST_VIRTUAL_REGISTER, thus it is target specific.
create_mem_ref_raw uses create_mem_ref_raw, thus it is target specific.
tree_create_mem_ref is a dispatching function, thus providing an interface
for target-independent code to call the appropriate create_mem_ref function.
There is nothing target specific about get_address_description.
* why is the whole df-problems.c file and a few other files target
specific? (Looks to me like these markers should be put fine-grained,
not on whole files)
Re. design breaks easily: There is no obvious way to check that all
functions that should be wrapped, are in fact wrapped.
This is why I like to make entire files target specific. If the general
theme of the file is to handle rtl, every function is suspect to be
target specific. Even if not now, a small change might make it so
tomorrow.
I suppose you
didn't find out what to wrap by trial and error. Do you have some
checking scripts that just list all functions that should be marked?
I've started out with making everything dealing with rtl target specific,
then searched for incidence of rtl handling functions and macros in the tree
files. TDEP-files was sort of a to-do list in the milepost branches.
Some more tricky files I went over function-by-function.
Some functions had to be pulled back into target-independent territory with
target vector references or dispatchers to keep the bulk of the tree
optimizers target independent.
ISTM it would be more robust to have a per-function-prototype marker
to signal that a function should be wrapped,
I don't see why; but I'd prefer the target specific prototypes to be
all grouped together.
and split off those
functions to separate files or a separate section in a file, instead
of wrapping the code in START/END_TARGET_SPECIFIC.
Agreed, but as I mentioned in my previous post, the resultant changes are
too big to be merged or reviewed together.
Once the basic infrastructure is in, we can move things around with patches
that have the sole objective of grouping target-specific and
target-independent stuff.
Otherwise, this patch is just waiting to be broken by ye random next
large patch (mem-ref2 merge, say) because nothing will catch missing
START/END_TARGET_SPECIFIC, reviewing is hard (you can't tell in a
patch whether a chunk is inside START/END_TARGET_SPECIFIC), and that's
all assuming people know what should be wrapped in the first place
(documentation).
Actually, be rather erring on putting stuff into the TARGET_SPECIFIC bucket
if they conceptually look like they might, I've seen little or no problems
with existing functions changing their status; but what I've seem are
textual merge problems, functions switching files, functions deleted and
added, that require manual attention during merge.