On 11/15/2014 06:46 PM, Sandra Loosemore wrote:
On 11/15/2014 04:49 PM, Jan-Benedict Glaw wrote:
Hi,
On Sun, 2014-11-16 00:36:27 +0100, Jan Hubicka <hubi...@ucw.cz> wrote:
Yep, it is because my code does not handle streaming of arrays
into the target optimization nodes. I will take a look on why
that array is really needed. It seems like a overkill?
I am looking into the nios2_register_custom_code and I do not quite
understand what it is good for? If it tracks customs codes function
wide, then perhaps target part of cfun would be better place to home
it. It it is unit wide, then saving/restoring does not seem to make
much sense.
Can you, please, explain me why this needs to be stored into target
option structure? If this is really needed, then we can always add
a support for streaming arrays, but I would preffer keeping that
structure small and simple ;)
Port maintainers Cc'ed.
I can explain why this is needed, at least.
The Nios II architecture optionally allows "custom instructions" that
are typically used to implement floating-point operations. The nios2
GCC backend knows to generate these instructions if the user tells it
what opcodes implement these instructions. This is typically done by
command-line options, but can also be done on a per-function basis by
means of target attributes or pragmas -- see
gcc/testsuite/gcc.target/nios2/custom-fp-* for examples. The
command-line options, attribute, and pragma support was a requirement
from Altera, so yes, this is really needed.
Ping. Do we have any strategy or timeline for fixing this yet? At the
very least, if it is determined to impose a new restriction against
using arrays in the saved option state, there must be a patch to clearly
document what is permissible. Otherwise I think the generic code must
be fixed to support what the nios2 back end is already doing and which
previously worked per the existing documentation.
-Sandra
