> > > So - how difficult is it to fix BRIG to not use MULT_HIGHPART_EXPR if > > > not supported?
Richard, how should we proceed from here? Do you like the solution in the initial mail, or would you prefer something else? FWIW I agree with Pekka, no need to burden BRIG FE with expanding mul-highpart. > > Pekka, can you comment? I think you have fallback paths for vector types > > only at the moment? > > I think it involves pretty much moving the code of your patch to the > BRIG frontend. > To me it'd look a bit wrong in terms of "division of responsibilities" > as this is not really > frontend-specific as far as I understand (even if BRIG/HSAIL happened > to be the only language > supporting them currently). > > > Does BRIG have mult-highpart for 64-bit integers? On 32-bit targets we > > won't be able to easily expand them (but on 64-bit targets it is fine). > > Yes it does. 32b targets are not high priority for BRIG FE at this > point, so I wouldn't > worry about this as we assume HSA's "large" model is used, so this is likely > not > the only problem when trying to generate for 32b machines. > > > For scalar types I think we should prefer to implement a generic expansion > > rather than have the frontend query the backend. For vector types I am not > > sure. > > In my relatively gcc-uneducated humble opinion these both belong more > naturally to a > target-specific expansion or "legalization" pass, which tries to > convert tree nodes to what the target > can support. > > BR, > Pekka >
