Displaying 6 results from an estimated 6 matches for "unsimplifiable".
2013 Feb 20
0
[LLVMdev] [RFC] NoBuiltin Attribute
...still not understanding a few things in this thread, including one
here: if you annotate only the calls to print (say) then how do you handle
the indirect calls that the back end might yet optimize down to a constant
& then attempt to simplify? Would all indirect calls be annotated with all
the unsimplifiable function names?
> Putting the attribute on the caller of printf, i.e. "func_a" is what I
object to. If it's in the form of "define @func_a() no-builtin-printf
{...body...}", then the attribute may be lost during inlining of func_a.
I believe Bill had suggested solving...
2013 Feb 20
4
[LLVMdev] [RFC] NoBuiltin Attribute
On 2/19/2013 11:11 PM, Chris Lattner wrote:
>
> I still really have no idea what problem you think you are solving.
Dealing with different attributes on different functions.
--- a.c ---
void func_a() {
printf(...);
}
--- b.c ---
void func_b() {
printf(...);
func_a();
}
a.c is compiled with no-builtin-printf, b.c has no such options.
The prototype approach (no-builtin on the
2013 Feb 20
3
[LLVMdev] [RFC] NoBuiltin Attribute
...ing a few things in this thread, including one
> here: if you annotate only the calls to print (say) then how do you
> handle the indirect calls that the back end might yet optimize down to a
> constant & then attempt to simplify? Would all indirect calls be
> annotated with all the unsimplifiable function names?
Something like that. Indirect calls could be conservatively marked as
"no-builtin-everything", to limit the amount of data attached to them.
Metadata could be used to indicate exactly which target functions were
of interest, but it could be ignored without violating t...
2014 Jan 22
3
[LLVMdev] Why should we have the LoopPass and LoopPassManager? Can we get rid of this complexity?
On Wed, Jan 22, 2014 at 1:01 AM, Andrew Trick <atrick at apple.com> wrote:
> On Jan 22, 2014, at 12:44 AM, Chandler Carruth <chandlerc at gmail.com>
> wrote:
>
>
> On Wed, Jan 22, 2014 at 12:33 AM, Andrew Trick <atrick at apple.com> wrote:
>
>> > There appear to be two chunks of "functionality" provided by loop
>> passes:
>> >
2013 Feb 20
1
[LLVMdev] [RFC] NoBuiltin Attribute
...still not understanding a few things in this thread, including one here: if you annotate only the calls to print (say) then how do you handle the indirect calls that the back end might yet optimize down to a constant & then attempt to simplify? Would all indirect calls be annotated with all the unsimplifiable function names?
>
To David:
The point is that you're not marking just the calls to printf, you're marking *all* call sites compiled in the scope of fno-builtin. The indirect call case, for example:
void foo() {
auto fp = printf;
fp();
}
If built with -fno-builtin, the indirect c...
2013 Feb 20
0
[LLVMdev] [RFC] NoBuiltin Attribute
...in this thread, including one
>> here: if you annotate only the calls to print (say) then how do you
>> handle the indirect calls that the back end might yet optimize down to a
>> constant & then attempt to simplify? Would all indirect calls be
>> annotated with all the unsimplifiable function names?
>
>
> Something like that. Indirect calls could be conservatively marked as
"no-builtin-everything", to limit the amount of data attached to them.
Metadata could be used to indicate exactly which target functions were of
interest, but it could be ignored without...