On Mon, Jul 29, 2024 at 9:26 PM Tobias Burnus <tbur...@baylibre.com> wrote:
>
> The problem is code like:
>
> MEM <uint128_t> [(c_char * {ref-all})&arr2]
>
> where arr2 is the value expr '*arr2$13$linkptr'
> (i.e. indirect ref + decl name).
>
> Insidepass_omp_target_link::execute, there is a call to
> gimple_regimplify_operands but the value expression is not
> expanded.There are two problems: ADDR_EXPR is no handling this and while
> MEM_REF has some code for it, it doesn't handle this either. The
> attached code fixes this. Tested on x86_64-gnu-linux with nvidia
> offloading. Comments, remarks, OK? Better suggestions? * * * In
> gimplify_expr for MEM_REF, there is a call to is_gimple_mem_ref_addr which
> checks for ADD_EXPR
> but not for value expressions. The attached match handles
> the case explicitly, but, alternatively, we might want
> move it to is_gimple_mem_ref_addr (not checked whether it
> makes sense or not).
>
> Where is_gimple_mem_ref_addr is defined as:
>
> /* Return true if T is a valid address operand of a MEM_REF. */
>
> bool
> is_gimple_mem_ref_addr (tree t)
> {
> return (is_gimple_reg (t)
> || TREE_CODE (t) == INTEGER_CST
> || (TREE_CODE (t) == ADDR_EXPR
> && (CONSTANT_CLASS_P (TREE_OPERAND (t, 0))
> || decl_address_invariant_p (TREE_OPERAND (t, 0)))));
> }
I think iff then decl_address_invariant_p should be amended.
Why is the gimplify_addr_expr hunk needed? It should get
to gimplifying the VAR_DECL/PARM_DECL by recursion?
> Tobias
