Hi Ian, sorry for the late response. I was on vacation for the last two weeks. (Btw. thats also the reason for the S/390 daily build system being down over the last days. It is back online now.)
> > The lengthy part is necessary to have attribute getter functions which > > allow to specify the alternative as additional parameter. I admit > > that these are a lot of quite mechanical changes to the genattr stuff > > but my hope was that these getter functions might be useful in other > > contexts as well. > > I'm not sure how. Without having any concrete plans I could imagine that there might be other special insn attributes added which might be used to influence the alternative decisions done in reload and co. . Not that the process of finding the right alternative isn't already complicated enough I think insn attributes would be a nice interface to enable the back end to influence that process. > Right now you can refer to the attribute values for an alternative > when computing a different attribute for that alternative. Can you > use that ability to compute your enabled alternative? I'm not sure how this can buy me anything here. What I need is access to the value of an insn attribute for a *different* alternative. The only thing I could think of would be an insn attribute defining a vector of flags saying which alternatives are enabled. This attribute would return the whole vector for all the alternatives. This would avoid the new getter functions but it is not really a beautiful approach - right?! Bye, -Andreas-
