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
