>Something along these lines may be useful to do in the vectorizer when we
>get code like this:
> > ((char)x) = ((char)( ((int)((char)x)) << ((int)c) ) )
>and don't feel like doing all the unpacking of chars to ints and then
>packing the ints to chars after the shift. An alternative could be
...
>Ah, right... I wonder if we can keep the loop structure in place, even
>after completely unrolling the loop - I mean the 'struct loop' in
>'current_loops' (not the actual CFG), so that the "SLP in loops" would
have
>a chance to at least consider vectorizing this "loop".
Having a "loop" str
> > > "Linthicum, Tony" <[EMAIL PROTECTED]> writes:
...
> > > * What is the best way to access target level cost information?
> >
> > I'm sure you know that the loop code does this by generating RTL and
> > asking for the cost of it (computation_cost in tree-ssa-loop-ivopts.c).
>
> Which should
s lists the way it shouldn't.
> Lists are being copied, edited and deleted directly without interaction
> with sched-deps.c . What the scheduler really needs is the following
> set of primitives:
>o FOR_EACH_DEP (insn, which_list, iterator, dep) - walk through
> insn's w
David Edelsohn <[EMAIL PROTECTED]> wrote on 23/03/2007 19:04:57:
>I am pleased to announce that the GCC Steering Committee has
> appointed Ayal Zaks as Modulo Scheduler maintainer.
>
>Please join me in congratulating Ayal on his new role.
> Ayal, please update
"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 25/03/2007 05:19:41:
> On 3/23/07, Alexander Monakov <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> >
> > I would be pleased to see Ayal Zaks as my mentor, because proposed
> > improvement is
As you noted, when the scheduler decides between stores and adds it always
prefers the adds (first at t = 5), due to its critical path heuristic. In
Jon's example, stores seem "costly" as one cannot issue a load or store
immediately following a store. Perhaps the scheduler could take the
(resou
> Vasanth <[EMAIL PROTECTED]>
> I am using powerpc-eabi-gcc (3.4.1) and trying to retarget it for a
> fully pipelined FPU. I have a DFA model for the FPU. I am looking at
> the code produced for a simple FIR algorithm (a loop iterating over an
> array, with a multiply-add operation per iterati
(sorry for replicated submissions, had to convert to plain text)
>2011/7/27 Revital1 Eres
>
>Hello Richard,
>
>
>> I ask because in the final range:
>>
>> start = early_start;
>> end = MIN (end, early_start + ii);
>> /* Schedule the node close to it's predecessors. */
>>
endencies is definitely important.
>
> Ayal Zaks writes:
> >>> I ask because in the final range:
> >>>
> >>> start = early_start;
> >>> end = MIN (end, early_start + ii);
> >>> /* Schedule the node close to it'
2011/8/8 Richard Sandiford
>
> Ayal Zaks writes:
> >> OK. For the follow-on iv patch, it seemed easier to keep both bounds
> >> inclusive for the loop, then make the "end" exclusive when setting the
> >> out parameters. (Note that there shouldn'
>AFAIK SMS will not do speculative memory access.
Right, SMS does no speculative memory access. Though that might not be
a bad idea...
Ayal.
2011/8/11 Revital Eres
>
> Hello,
>
> >> I appriciate explanation regarding the following piece of code in
> >> sched_analyze_insn function (sched-deps.c)
"Bingfeng Mei" wrote on 30/01/2009 14:44:01:
> Hello,
> I try to make modulo scheduling work more efficiently for our VLIW
target. I
> found one serious issue that prevents current SMS algorithm from
achieving
> high IPC is so-called "transitive closure" problem, where scheduling
window is
> only
l, not many loops are candidates for software pipelining.
Thanks.
>
I would suggest to check the actual compile-time and memory usage, and try
to reduce them later if needed. Modulo-scheduling is not a compile-time
cheap optimization in general.
Ayal.
> Cheers,
> Bingfeng
>
> >
s, Ayal.
> Thanks,
> Revital
>
> * modulo-sched.c (sms_schedule_by_order): Pass the actual
> schedulable rows to compute_split_row.
>
> [attachment "patch_sms_12_3.txt" deleted by Ayal Zaks/Haifa/IBM]
Steven Bosscher <[EMAIL PROTECTED]> wrote on 14/03/2006 01:32:09:
> Hi Ayal,
>
> The SMS implementation in GCC, in modulo-sched.c, uses line notes
> to find insn locations, see find_line_note. Why are you using
> line notes instead of insn locators? Line notes are on the list
> of Things That Sh
> Roger Sayle <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
>
> 03/05/2006 05:03 PM
>
> To
>
> Mark Mitchell <[EMAIL PROTECTED]>
>
> cc
>
> Richard Henderson <[EMAIL PROTECTED]>, gcc mailing list ,
Leehod
> Baruch <[EMAIL PROTECTED]>, Mircea Namolaru/Haifa/[EMAIL PROTECTED],
> <[EMAIL PROTECTED]
> This status report has been a long time coming, for which I apologize.
>
> As fwprop is no longer on the table for 4.2, and as the vectorizer
> improvements seem to have stalled due to a combination of lack of review
> and Dorit's leave,
That is unfortunate. Dorit did make a sincere effort to p
"Richard Guenther" <[EMAIL PROTECTED]> wrote on 06/06/2006
16:58:27:
> On 6/6/06, Ayal Zaks <[EMAIL PROTECTED]> wrote:
> >
> > > This status report has been a long time coming, for which I
apologize.
> > >
> > > As fwprop is no longer on t
Acronymed GREPS (... just what you were looking for), is to be held on
September 16 in Brasov, Romania, co-located with PACT. We'd like to bring
this workshop to your attention; the submission site is now open until July
24, after the upcoming GCC Developers' Summit. For more details see
http://sy
Zdenek Dvorak <[EMAIL PROTECTED]> wrote on 30/06/2007 09:55:45:
> Hello,
>
> > By "this change" I mean just commenting out the check in
> > doloop_condition_get. After applying the patch that introduced DOLOOP
> > patterns for SPU
(http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01470.html)
> > we ne
Zdenek Dvorak <[EMAIL PROTECTED]> wrote on 30/06/2007 10:52:32:
> Hello,
>
> > It doesn't seem that the number of iterations analysis from loop-iv.c
deals
> > with EQ closing branches.
>
> loop-iv works just fine for EQ closing branches.
>
Thanks for the clarification (I didn't see EQ in iv_numbe
Zdenek Dvorak <[EMAIL PROTECTED]> wrote on 30/06/2007 20:36:12:
> Hello,
>
> > > > It doesn't seem that the number of iterations analysis from
loop-iv.c
> > deals
> > > > with EQ closing branches.
> > >
> > > loop-iv works just fine for EQ closing branches.
> > >
> >
> > Thanks for the clarificati
> Is anyone else seeing failures on the gcc.dg/matrix tests? I am getting
> the following failures on IA64 HP-UX:
>
Hope Razya can help spot the cause, after she returns from vacation later
this week.
Ayal.
> FAIL: gcc.dg/matrix/matrix-1.c scan-ipa-dump-times Flattened 3 dimensions
1
> FAIL: g
t 13, 2007
Workshop date: September 16, 2007
Ayal Zaks/Haifa/IBM wrote on 26/06/2007 18:08:43:
> Acronymed GREPS (... just what you were looking for), is to be held on
> September 16 in Brasov, Romania, co-located with PACT. We'd like to bring
this
> workshop to your attention; the sub
"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 01/08/2007 18:27:35:
> On 8/1/07, Tehila Meyzels <[EMAIL PROTECTED]> wrote:
> > "Daniel Berlin" <[EMAIL PROTECTED]> wrote on 31/07/2007 18:00:57:
> >
> > >
> > > I agree with you for conditional stores/loads.
> >
> > Great!
> >
> > >
> > > The unconditi
only must_preceed insn 58 because the latency between 61->58 is
> 14 which causes the end boundary of the window to be 0.
>
> Thanks,
> Revital
>
> [attachment "test.c.172r.sms" deleted by Ayal Zaks/Haifa/IBM]
Indeed the latency between 61->58 is 14 causing en
Revital1 Eres/Haifa/IBM wrote on 14/11/2007 18:46:14:
>
> >
> > When scheduling insn 58, we calculate a window of possible cycles
according
> > to already scheduled predecessors and successors. This window looks
like a
> > parallelogram in general rather than a rectangle: in the first cycle
there
28 matches
Mail list logo
