Enhancement: "notnull" modifier for a value

[llvmbot]

Bugzilla Link	11224
Version	trunk
OS	All
Reporter	LLVM Bugzilla Contributor

Extended Description

Iave a language feature called "auto class creation". when a pointer is null and i access this field, the field is filled with values.
One problem i have is that this check is done every time i access a field
The problem is that a allocated memory is not null, but llvm dosent know that
So it checks it against 0 again and again
The other problem is the allocation. in some cases (the start of a function), the probability that the mem should be allocated is 100%, in other cases the probability is very low. so the allocation should not be inlined
(and maybe the basic block for the mem allocation should be at the end of the function so that no jump is required)

So the solution is a "notnull" flag to constant fold "icmp eq %type* %value, null" to "i1 0"

[llvmbot]

Testcase?

[llvmbot]

Readable unoptimized code (look at global.init$)

[llvmbot]

Source code:

static init
begin
var a: A
a.a
a.b
end

class A
static A.a
begin
log('a')
end
static A.b
begin
log('b')
end

LLVM file is attached.
Look at @"global.init$" (line 505)

label386 and label398 are the checks

[llvmbot]

Running "opt -basicaa -gvn" on your testcase eliminates one of the two checks
in global.init. Did you try with trunk?

[llvmbot]

as you see in the test case, yes. It's correct because a is initialized to null.
What I want to reach with the enhancement is to eliminate the second check.
(And btw the check fail block could be moved somewhere else for branch prediction issues, but that's an other 'bug')

[llvmbot]

Are you saying that you want the optimizers to understand that create.A
never returns a null value?

[llvmbot]

correct.

[llvmbot]

If you run opt at -O3 on this testcase then it inlines all of your small
functions (like create.A) and removes the check. So is there really a
problem with this testcase?

[llvmbot]

The second check is not removed.
adding notnull to @​create.A is destroyed when inlining it, that's correct. So i should either not inline it or mark malloc with notnull, too (and hope that lib analysis dont remove it)

[llvmbot]

So you still see a check after inlining? If so, please attach your testcase
after inlining and explicitly state which check it is that you think should
be deleted.

[llvmbot]

See Comment 2

The second check cannot be removed until the feature I'm asking for is implemented. (but you can post a patch for me)

[llvmbot]

That's unoptimized code. I'm asking you to point to the check you would like
removed in optimized code.

[llvmbot]

I mean, I would like you to attach optimized code, and point to what is wrong
with it.

[llvmbot]

Optimized testcase
This is the testcase after opt -O3

label 414 is the label where it will never jump to.

Tell me if you need test cases with 32bit layout

[llvmbot]

Do you mean label414.i?