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:
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 G
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 th
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...
FWIW,
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 bee
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.
:-( Wou
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 tha
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 (conve
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.
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(CO
> 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
co
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.
> 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
> > 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 implementa
> 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.
Message---
> 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_ed
>>> 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.
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
> 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 th
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
In addition, my current email conversation with Dorit about GPU
integration would be better suited to high level optimisation and code
separation with multiple backends.
Eric Christopher wrote:
This and the register changes come close to multi-arch gcc. Is that a
direction we want to go? Hist
> > 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
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
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 f
> 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
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),
> 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.
> 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 architect
This and the register changes come close to multi-arch gcc. Is that a
direction we want to go? Historically we have not tried to support
Personally I'd love to see us go this way if it doesn't inconvenience
us too much.
From what I remember of the MeP port it was pretty clean and wouldn't
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. COPSImod
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 gcc?
31 matches
Mail list logo
