On 11/19/2014 09:34 PM, Jan Hubicka wrote:
[snip]
I see three possible fixes:
1) extend the AWk script to recognize arrays and stream them specially
(it already recognizes string so it is not hard to do, just bit wasteful)
2) add attribute to .opt file allowing user to specify his own
compare/hash/stream-in/stream-out functions
3) avoid using arrays in the backend. I think it is doable - the target
structure contains string representation of the arrays
(nios2_custom_fpu_cfg_string) and therefore saved_custom_code_status/
saved_custom_code_index does not really need to hit the LTO stream
at all. Question is where to place them and I think target specific
part of cfun is probably resonable choice.
Just to clarify here, nios2_custom_fpu_cfg_string doesn't hold the
complete state information. That option is used to specify some sets of
predefined custom instructions that can be augmented with various
-mcustom-foo= options for individual instructions foo (or you can just
use the -mcustom-foo= options). The arrays are used to hold the
combined state of all these different options for error-checking and
lookup purposes. I think it is true that we could rewrite this code to
reconstruct the arrays from the original options, but it's not something
I'd really want to undertake if the generic streaming code can be fixed
instead.
As for AWk-fu, 2 is probably easier than 1, but both are not hard - one just
need to follow what is already done for strings and introduce third type of
variable.
Unless someone beats me, I will probably go for 1 since I am not very familiar
with the backend and array support may come handy in future.
As for timeline, I have a workshop next week and need to prepare draft for it.
So ideally I would like to work on this only after the workshop (ending
November 28). I would be also happy to help anyone interested to help (I am
just bit slow on portable AWK hacking).
OK. I'm not so worried about getting this fixed by a certain date as
about having a plan for fixing it.
-Sandra
