On 07.07.2011 20:18, Vladimir Makarov wrote:
On 07/01/2011 10:50 AM, Andrey Belevantsev wrote:
On 26.05.2011 17:32, Andrey Belevantsev wrote:
On 25.05.2011 19:31, Bernd Schmidt wrote:
On 05/25/2011 03:29 PM, Andrey Belevantsev wrote:
I think the hook is a better idea than the attribute because nobody will
care to mark all offending insns with an attribute.
I don't know. IIRC when I looked at sh or whatever the broken port was,
it was only two insns - there would still be some value in being able to
assert that all other insns have a reservation.
OK, I will take a look on x86-64 and will get back with more information.
Andrey
So, I have made an attempt to bootstrap on x86-64 with the extra assert
in selective scheduling that assumes the DFA state always changes when
issuing a recog_memoized >=0 insn (patch attached). Indeed, there are
just a few general insns that don't have proper reservations. However, it
was a surprise to me to see that almost any insn with SSE registers fails
this assert and thus does not get properly scheduled.
Overall, the work on fixing those seems doable, it took just a day to get
the compiler bootstrapped (of course, the testsuite may bring much more
issues). So, if there is an agreement on marking a few offending insns
with the new attribute, we can proceed with the help of somebody from the
x86 land on fixing those and researching for other targets.
The changes in sel-sched.c is ok for me. i386.md changes look ok for me too
but you should ask a x86 maintainer to get an approval for the change.
I think you should describe the attribute in the documentation because it
is common for all targets.
I can not approve common.opt changes because it makes selective scheduler
is default for the 2nd insn scheduling for all targets. Such change should
be justified by thorough testing and benchmarking (compilation speed, code
size, performance improvements) on several platforms (at least on major ones).
I didn't intend to enable sel-sched for all targets, the patch was just an
RFC to see whether there is an agreement about usefulness of such
attribute, and the common.opt change was to show how I tested the patch. I
am sorry for not making it clear in the mail.
I am planning to check Bernd's thought about whether I selected the right
-mcpu switch for testing, as I was under impression that nowadays this
should be autodetected by configure. I will also modify the attribute as
suggested. Then we can discuss further. I am going to leave on vacation
soon though so I don't know when exactly I can proceed with this.
Thanks!
Andrey
