[Libre-soc-bugs] [Bug 577] gcc compiler, binutils and assembly macros for OpenPOWER-SV

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=577

--- Comment #1 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
in issue #615 i am keeping notes from various conversations with ppc binutils
and gcc maintainers, as well as OPF.

summary of OPF advice: an architectural fork inside gcc will not be well
received due to the implication of ecosystem fragmentation.

one idea came up from David to use the same trick intended for v3.1: there they
intend mark entries in rs6000.md as "v3.1prefixableto64bit", and David said he
would have no problem with us doing the same thing: set attribute
"svp64vectoriseable".

for us this would indicate that when it came to assembly output there would be
a special 32bit EXT01 assembly instruction outputted at the front of any
instruction marked with the attribute.

Segher then suggested *redefining* the underlying data structure that is used
by the macro system for representing registers.

this combination effectively empowers all svp64-marked macro patterns to have a
massive addition set of matching capabilities.

on registers alone this would be:

* RT=s RA=s RB=s
* RT=v RA=s RB=s
* ....
* RT=v RA=v RB=v

when element-width overrides are introduced these permutations multiply by 4
for source elwidth override *and another* four for dest elwidth override.

when additional capabilities such as a
saturation are also added, the thought of creating a macro file even one that
is autogenerated with all these permutations *per macro* listed explicitly is,
at best, described as insane and, frankly, stupid.

a little intelligent thought shows that the pattern-matching can be done
implicitly (using existing rs6000.md patterns) when marked with an appropriate
attribute.

this will allow us to do very basic (and i mean very basic) matching between
vector patterns and svp64-attribute-marked rs6000.md macros.

anything not part of a conditional if/else computation for example: straight
unconditional for-loops.

where it gets more complicated is anything that's computed which is to be used
for a branch decision.  this requires predication (like is used in arm32bit)
which is not a "normal" part of ppc except in very special unique
circumstances.

avoiding that situation for now and simply doing unconditional for-loop
expansion would still be a huge leap forward.

-- 
You are receiving this mail because:
You are on the CC list for the bug.