In http://gcc.gnu.org/ml/gcc/2007-03/msg01007.html, Steven Bosscher wrote:
All of this feels (to me anyway) like adding a lot of code to the
middle end to support MEP specific arch features. I understand it is
in the mission statement that more ports is a goal for GCC, but I
wonder if this
Steven Bosscher wrote:
All of this feels (to me anyway) like adding a lot of code to the
middle end to support MEP specific arch features. I understand it is
in the mission statement that more ports is a goal for GCC, but I
wonder if this set of changes is worth the maintenance burden...
On 3/28/07, Julian Brown [EMAIL PROTECTED] wrote:
Steven Bosscher wrote:
All of this feels (to me anyway) like adding a lot of code to the
middle end to support MEP specific arch features. I understand it is
in the mission statement that more ports is a goal for GCC, but I
wonder if this
Steven Bosscher wrote:
On 3/28/07, Julian Brown [EMAIL PROTECTED] wrote:
Steven Bosscher wrote:
All of this feels (to me anyway) like adding a lot of code to the
middle end to support MEP specific arch features. I understand it is
in the mission statement that more ports is a goal for GCC,
Jeffrey Law [EMAIL PROTECTED] writes:
* expmed.c (expand_mult): If the variable operand is a coprocessor
value, use a coprocessor accumulator.
Why? Isn't this an architecture specific decision to make? Iff this
will ever be useful to other architectures than MEP (which
On Mar 26, 2007, at 9:28 PM, DJ Delorie wrote:
No, it's more like this:
typedef int copsi __attribute__((mode(COPSI)));
void foo (int *a, copsi *b, int i)
{
while (i--)
{
*a *= 2;
*b *= 2;
}
}
This will keep both the core multiplier and the coprocessor multiplier
busy.
:-(
Jupming in at a random point.
First, unless my memory is completely faulty, Stan Cox should be named
in this change too. ISTR he did the initial implementation for one
particular coprocessor, which we later generalised to cover other user-
configurable coprocessors. However, as DJ says, it's
Coprocessor types - the MeP chip has optional coprocessors, each with
their own register sets. They need their own internal types (mostly
to keep track of which unit to use), which we've created by prefixing
the existing types with COP (i.e. COPSImode, COPDFmode, etc). This
affects the
DJ Delorie [EMAIL PROTECTED] writes:
Coprocessor types - the MeP chip has optional coprocessors, each with
their own register sets. They need their own internal types (mostly
to keep track of which unit to use), which we've created by prefixing
the existing types with COP (i.e.
Earlier you sent out a patch preventing inlining. That suggests that
you can not compile code to run on both the main processor and the
coprocessor at the same time.
No, that's not how it works. We always support both the main
processor and the coprocessor at the same time, in the same
DJ Delorie [EMAIL PROTECTED] writes:
If that is correct, then why do you need these coprocessor modes?
For example, why can't you set the mode in struct machine_function
and check that when recognizing insns?
No, it's more like this:
typedef int copsi __attribute__((mode(COPSI)));
On 3/27/07, DJ Delorie [EMAIL PROTECTED] wrote:
* postreload.c (reload_cse_move2add): Don't look for strict lowparts
of coprocessor modes.
This changes is not in your patch.
* c-typeck.c (convert_for_assignment): Don't relax reference check.
And neither is this one.
On Tue, 2007-03-27 at 07:47 +0200, Steven Bosscher wrote:
On 3/27/07, DJ Delorie [EMAIL PROTECTED] wrote:
* postreload.c (reload_cse_move2add): Don't look for strict lowparts
of coprocessor modes.
This changes is not in your patch.
* c-typeck.c
DJ Delorie [EMAIL PROTECTED] writes:
Do you mean where is the best place to call these functions?
Yup.
Look at the calls to cgraph_mark_edge in ipa-inline.c
There is no such function. I couldn't find anything in ipa-inline
that (1) had access to both ends of the call edge, (2) was
Look at the calls to cgraph_mark_edge in ipa-inline.c
There is no such function. I couldn't find anything in ipa-inline
that (1) had access to both ends of the call edge, (2) was actually
called, and (3) was called before the inlining happened.
Sorry, I meant cgraph_mark_inline. It looks
---
From: DJ Delorie [EMAIL PROTECTED]
Subject: Re: core changes for mep port
Sent: 16 Mar '07 03:09
Do you mean where is the best place to call these functions?
Yup.
Look at the calls to cgraph_mark_edge in ipa-inline.c
There is no such function. I couldn't find
Guys - what branch/tag are you looking at doing this on?
It's only a couple of lines of code, do we need a branch for that?
Or do you mean the COPmode changes, which are bigger? They still
might be managable enough for trunk, if the timing is right.
Sorry, I meant cgraph_mark_inline. It looks like what you want to
me. But maybe I'm misreading it.
And cgraph_check_inline_limits
The magic place was cgraph_mark_inline_edges.
Turns out, when I changed disallow_* to allow_*, I forgot to reverse
the sense of the target's implementation,
DJ Delorie [EMAIL PROTECTED] writes:
Again my first reaction is whether it is necessary to compile code
which runs in two completely different modes in the same
compilation. If the functions can't call each other, why do they
need to be compiled together?
Why do *any* two functions
DJ Delorie [EMAIL PROTECTED] writes:
It sounds like we're not communicating properly. The total patch set
to support core vs vliw modes, the part that needs to manage inlined
functions by attribute, is a total of four lines of code in the core
(not including prototypes). The two hooks are:
if (targetm.disallow_inlining_p (node-decl, decl))
return false;
if (targetm.disallow_call_p (current_function_decl, function))
return error_mark_node;
I don't see a real problem with this, but I would prefer to see
allow_XX rather than disallow_XX. It's easier to
DJ Delorie [EMAIL PROTECTED] writes:
if (targetm.disallow_inlining_p (node-decl, decl))
return false;
if (targetm.disallow_call_p (current_function_decl, function))
return error_mark_node;
I don't see a real problem with this, but I would prefer to see
allow_XX
Do you mean where is the best place to call these functions?
Yup.
Look at the calls to cgraph_mark_edge in ipa-inline.c
There is no such function. I couldn't find anything in ipa-inline
that (1) had access to both ends of the call edge, (2) was actually
called, and (3) was called before the
I'm working on readying the Toshiba Media Processor (mep-elf) port for
contribution to GCC 4.x, but we added some core changes needed to
support it. The changes are listed below; I'd like some feedback
about these before I go too far with them. Are these concepts
acceptable for inclusion in
DJ Delorie [EMAIL PROTECTED] writes:
Coprocessor types - the MeP chip has optional coprocessors, each with
their own register sets. They need their own internal types (mostly
to keep track of which unit to use), which we've created by prefixing
the existing types with COP (i.e. COPSImode,
This and the register changes come close to multi-arch gcc.
Yup. The core has two modes, core and vliw, and the coprocessor(s)
each have their own units. The core manages the opcode processing,
but the coprocessor does the work.
Historically we have not tried to support different
Personally I'd love to see us go this way if it doesn't
inconvenience us too much.
It would be useful to be able to optimize each function as to, for
example, arm or thumb mode based on -Os and/or some heuristics. As a
long-term goal, at least.
On 14 Mar 2007 18:42:13 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
DJ Delorie [EMAIL PROTECTED] writes:
Coprocessor types - the MeP chip has optional coprocessors, each with
their own register sets. They need their own internal types (mostly
to keep track of which unit to use), which
This is what we do for the Cell also, we expect people to compile
using two different compilers right now, but we are actually looking
into doing an one source based compiling where some functions or
loops are pushed off to the SPUs via annotations like the OpenMP
ones.
It sounds like we're
29 matches
Mail list logo
