https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110248
--- Comment #7 from Kewen Lin <linkw at gcc dot gnu.org> --- (In reply to Richard Biener from comment #6) > (In reply to rsand...@gcc.gnu.org from comment #5) > > ivopts does have code to treat ifn pointer arguments specially, > > see get_mem_type_for_internal_fn &co. But like Kewen says, > > it's still only based on the mode. > > But the dump quoted says 'Type: POINTER ARGUMENT ADDRESS' which means > that doesn't work as desired. That is, the use is classified wrongly > and the above function only seems to be useful to get the mode of > the memory access done by the internal function? As Richard mentioned above, currently ivopts special-cases LEN and MASK load/store IFNs, USE_PTR_ADDRESS is the special use type for address-like use, currently it only handles the point arguments of these LEN and MASK load/store IFNs which will become an address when expanding the IFN statement. function find_address_like_use detects this kind of argument, determine_group_iv_cost and the others will treat USE_PTR_ADDRESS as the same as USE_REF_ADDRESS, excepting when rewriting it we will generate it with ADDR_EXPR (LEA). So costing doesn't distinguish USE_PTR_ADDRESS and USE_REF_ADDRESS. One thing seems to be improved is that unlike USE_REF_ADDRESS USE_PTR_ADDRESS uses will need ADDR_EXPR, it can generate something CSE'd, we can consider this during costing. > > USE_PTR_ADDRESS doesn't seem to be a very good match to capture > constraints for a memory dereference? > > > Personally I'd prefer an internal_fn rather than a gimple* though. > > It can be useful to test these things on a possible future statement, > > not just on one that already exists. > > Well yes, passing down a gimple * looks like too generic here. Maybe > use a code_helper so we can pass down MEM_REF for dereference context > and nothing (ERROR_MARK_NODE?) for plain address use? Thanks for the suggestions with internal_fn and code_helper! I thought gimple* can be generic but as the above comments I agree code_helper is better.
