New post-LTO OpenACC pass

[Bernd Schmidt]

On 09/25/2015 12:38 AM, Nathan Sidwell wrote:
> On 09/23/15 14:58, Nathan Sidwell wrote:
>> On 09/23/15 14:51, Bernd Schmidt wrote:
>>> On 09/23/2015 08:42 PM, Nathan Sidwell wrote:
>>>> We have to defer folding until we know whether we're doing host or
>>>> device compilation.
>>>
>>> Doesn't something like "symtab->state >= EXPANSION" give you that?
>
> I've tried limiting expansion by checking symtab->state.  I have been
> unable to succeed.
>
> It either expands too early in the host compiler, or it doesn't get
> expanded at  all and one ends up with an RTL call to the library
> function.   For instance there doesn't appear to be call to fold
> builtins when state == EXPANSION. lesser values are present in the host
> compiler before LTO write out, AFAICT.

That's a bit odd:

Breakpoint 5, (anonymous namespace)::pass_fold_builtins::execute 
(this=0x1ce89a0, fun=0x7ffff0858348) at ../../git/gcc/tree-ssa-ccp.c:2722
[...]
(gdb) p stmt
$3 = (gimple *) 0x7ffff0736d80
(gdb) pgg
warning: Expression is not an assignment (and might have no effect)
# .MEM_2 = VDEF <.MEM_1(D)>
_3 = acc_on_device (123);
(gdb) p symtab->state
$4 = EXPANSION

On the other hand, it's not considered a builtin:

(gdb) p gimple_call_builtin_p(stmt, BUILT_IN_ACC_ON_DEVICE)
$6 = false

This is the c-c++-common/goacc/acc_on_device-2.c testcase. Is that 
expected to be handled? If I change it to use __builtin_acc_on_device, I 
can step right into

Breakpoint 8, fold_call_stmt (stmt=0x7ffff0736e10, ignore=false) at 
../../git/gcc/builtins.c:12277
12277	  tree ret = NULL_TREE;

Maybe you were compiling without optimization? In that case 
expand_builtin_acc_on_device (which already exists) should still end up 
doing the right thing. In no case should you see a RTL call to a 
function, that indicates that something else went wrong.

Can you send me the patch you tried (and possibly a testcase you expect 
to be handled), I'll see if I can find out what's going on.


Bernd