On 12/03/15 12:07:35, Richard Biener wrote: > On Wed, 2 Dec 2015, Gary Funck wrote: > > OK. As I mentioned in a previous reply, originally we prefixed > > all "UPC" specific tree node fields and functions with UPC_ or upc_, > > but as we transitioned away from UPC as a separate language > > (ala ObjC) and made compilation conditional upon -fupc, an > > observation was made off list that since the base tree nodes > > are generic that naming UPC-related fields with "UPC" prefixes > > didn't make sense, so we removed those prefixes. There might > > be a middle ground, however, whee UPC_SHARED_TYPE_P() is preferred > > to SHARED_TYPE_P() because as you/others have mentioned, > > the term "shared" gets used in a lot of contexts. > > Yes, specifically for predicates/functions used in the middle-end.
OK > > > > + outer_is_pts_p = (POINTER_TYPE_P (outer_type) > > > > + && SHARED_TYPE_P (TREE_TYPE (outer_type))); > > > > + inner_is_pts_p = (POINTER_TYPE_P (inner_type) > > > > + && SHARED_TYPE_P (TREE_TYPE (inner_type))); > > > > + > > > > + /* Pointer-to-shared types have special > > > > + equivalence rules that must be checked. */ > > > > + if (outer_is_pts_p && inner_is_pts_p > > > > + && lang_hooks.types_compatible_p) > > > > + return lang_hooks.types_compatible_p (outer_type, inner_type); > > > > > > Sorry, but that can't fly with LTO. > > > > Can you elaborate? I'm not familiar with LTO or its requirements. > > With LTO the langhooks from the frontends are no longer available > so you'd need to implement the same logic in the LTO "frontend" > which means it wouldn't need a langhook at all because all information > would be contained in the middle-end representations. Still not quite understanding this one. Will need to take a more detailed look at LTO. > > We would also still need to make sure that the parts of the > > compiler that think that pointers are interchangeable with > > integers doesn't do that with UPC pointers-to-shared. > > I'm not very familiar with address-spaces but at least they > can be used to distinguish different pointer kinds (and prevent > conversions). Not sure if it would allow different behavior > for a simple plus. > > Note that I belive you should lower your "pointer" representation > when you lower the rest (I suppose you lower this now only during > RTL generation?) We lower all *operations* (plus/minus, get/put, conversions) in the UPC lowering pass, which runs just before c_genericize(). We retain the pointer-to-shared-qualified type in the tree, often wrapped by a conversion to the internal representation type. As I mentioned previously, we ran into some issues try to lower to just the representation type, but I don't recall the specifics. I can try and check on that. The RTL will see the pointer-to-shared types, but won't see things like indirections through them, addition/subtraction and so on, because that was handled in the lowering pass. We could probably lower most all things in the front-end when the program is being parsed, but it would make the initial tree difficult to understand and would push the lowering logic into front-end/parser which makes the implementation less modular. > > > Use a function please. No such unwiedlingly large macros. > > > > OK. Are static inline's OK here? > > Implementations in non-headers are prefered, but yes. I doubt that performance will be impacted much by making the call out-of-line. Will take a look into whether that is feasible. > > > > +/* UPC pointer to shared qualified object representation */ > > > > +#define upc_pts_rep_type_node global_trees[TI_UPC_PTS_REP_TYPE] > > > > +#define upc_char_pts_type_node global_trees[TI_UPC_CHAR_PTS_TYPE] > > > > +#define upc_phase_field_node global_trees[TI_UPC_PHASE_FIELD] > > > > +#define upc_thread_field_node global_trees[TI_UPC_THREAD_FIELD] > > > > +#define upc_vaddr_field_node global_trees[TI_UPC_VADDR_FIELD] > > > > +#define upc_null_pts_node global_trees[TI_UPC_NULL_PTS] > > > > + > > > > > > Ugh. Please no further global tree nodes. > > > Do you really need all of them in middle-end code? > [...] > After gimplification. I realize the global trees are in a messy > state already and most of them should be moved to frontend specific > places. It would be a start if you do that. And lowering your > pointer representation earlier will probably make that easier. I will review the code to see if they can be moved to front-end specific procedures/files.
