On 05/10/2017 02:27 PM, Jakub Jelinek wrote:
On Wed, May 10, 2017 at 09:57:56PM +0200, Uros Bizjak wrote:
BTW: This patch now catches 417 cases (instead of 200+) in linux
build, including e.g.:
(parallel [
(set (reg:CCZ 17 flags)
(compare:CCZ (lshiftrt:SI (reg:SI 4 si [orig:93 _10 ] [93])
(const_int 1 [0x1]))
(const_int 0 [0])))
(set (reg:DI 4 si)
(zero_extend:DI (lshiftrt:SI (reg:SI 4 si [orig:93 _10 ] [93])
(const_int 1 [0x1]))))
])
That looks nice. So, I think we need analysis on what order which targets
use. I have looked at mn10300.md, I see {add,sub}si3_flags patterns that
would need PARALLEL reordering for this compare-elim.c change and then
cmp_liw vs. liw_cmp patterns I have no clue what they do and whether
compare-elim.c would care about those or not (they have UNSPECs). Jeff/Alex?
No idea what the cmp_liw and liw_cmp patterns are -- they were added
after my involvement with the mn103 ended.
I know it's been discussed before, but all that's needed here is to put
the assignment to CC_REG first in patterns were CC_REG is assigned a
useful value, right? For patterns were CC_REG is clobbered, we leave
them as-is, right?
Does this impact logicals or just arithmetic? If it hits logicals,
there's a few more patterns in the mn103 port and likely the rx port as
well. But the changes look highly mechanical.
Furthermore, it's trivial for me to build this port through newlib. So
I could build before the change, stash away the resulting libc.a, then
build after the change and compare the contents of the resulting
objects. In theory they should be identical unless I'm missing something.
I would say don't let the mn103 stop this work. If the work goes
forward, I'll own cleaning up the mn103. I don't mind assigning the
cleanup of rx to Nick to be done after the generic changes are done.
That just leaves visium which Eric B. owns. Note that I can test visium
in the same way I can test mn103 and rx, so if someone does the visium
work I can test it.
Jeff
