Hi Kenneth,
>>> I have no idea how to make use of llvm.invariant to help
>>> devirtualization. If no use or other use case for them can be
found,
>>> maybe they should be removed.
>>
>> the dragonegg plugin uses llvm.invariant to help the code generators
>> optimize the code it produces for builtin_init_trampoline. It writes
>> some values into memory which is then constant forever after. Because
>> pointers to this memory are passed into all kinds of functions, the
>> optimizers don't understand that the values are constant without
help,
>> thus the use of llvm.invariant. It doesn't work very well, but it
is
>> still better than not doing it at all.
>
> I suppose the LLVM trampoline intrinsics aren't well supported? Or do
> they just not fit your use case?
the LLVM trampoline intrinsic works fine, but doesn't work quite the same as
the GCC builtins: GCC has two trampoline builtins that LLVM combines into one
intrinsic. In llvm-gcc this "impedance mismatch" was overcome by
tweaking the
nested function lowering code, but in dragonegg I don't have the luxury of
modifying GCC's code, so I had to instead emit a bunch of ugly fixup code
when
lowering the GCC intrinsics. The optimizers find it hard to clean up the
resulting mess without help.
Ciao,
Duncan.