llvm dev - Apr 2017 - Disable optimization on basic block level

Hi folks,

During an IR function pass I want to annotate certain basic blocks to avoid
later optimization on them. I know I, I can disable optimization on
function granularity, but how to do so on basic block level?

Cheers,
Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170421/c8f303d2/attachment.html>

I don't think there is any way to do this in LLVM. What would that be useful
for?

- Matthias
> On Apr 21, 2017, at 6:14 AM, Max Muster via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi folks, 
> 
> During an IR function pass I want to annotate certain basic blocks to avoid
later optimization on them. I know I, I can disable optimization on function
granularity, but how to do so on basic block level?
> 
> Cheers,
> Max
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

+CC llvm-dev again!
> On Apr 24, 2017, at 12:46 AM, Max Muster <olimex5812 at gmail.com>
wrote:
> 
> Hi Matthias,
> 
> thanks for your answer.
> 
> The reason it would be useful for me is that I am inserting a basic block
at IR level as part of a function pass.
> However, LLVM's optimization passes are clever enough to optimize my
inserted code at IR level.
Of course a compiler is only concerned about the observable effects of a
program. Whether there is an extra block or not is not considered part of that.
You should probably reconsider what you actually want here. We also cannot
really help you with the information given so far, I am pretty sure you have
higher goals than just keeping a basic block (otherwise you could just stop the
compiler after your pass and the block would stay :)
> 
> Are there other possibilities to avoid optimization at certain parts of IR
code?
Add some instructions triggering observable effects. Typical examples for
"tricking" optimizers would be volatile loads or volatile asm blocks
(possibly without actual instructions inside).

- Matthias

How do you disable optimization for a function?

I ask because my application often compiles machine-generated code that
results in pathological structures that take a long time to optimize, for
little benefit. As an example, if a basic block has over a million
instructions in it, then DSE can take a while, as it is O(n^2) in the
number of instructions in the block. In my application (at least), this
block is typically executed only once at run time, and is not part of a
loop, so I really don't care about code quality for that block.

I am able to identify some of these conditions. I would like to tell LLVM
to "not try so hard" on the pathological blocks, while keeping
optimizations active for ordinary cases.


On Mon, Apr 24, 2017 at 1:17 PM, Matthias Braun via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> +CC llvm-dev again!
>
> > On Apr 24, 2017, at 12:46 AM, Max Muster <olimex5812 at
gmail.com> wrote:
> >
> > Hi Matthias,
> >
> > thanks for your answer.
> >
> > The reason it would be useful for me is that I am inserting a basic
> block at IR level as part of a function pass.
> > However, LLVM's optimization passes are clever enough to optimize
my
> inserted code at IR level.
> Of course a compiler is only concerned about the observable effects of a
> program. Whether there is an extra block or not is not considered part of
> that. You should probably reconsider what you actually want here. We also
> cannot really help you with the information given so far, I am pretty sure
> you have higher goals than just keeping a basic block (otherwise you could
> just stop the compiler after your pass and the block would stay :)
>
> >
> > Are there other possibilities to avoid optimization at certain parts
of
> IR code?
> Add some instructions triggering observable effects. Typical examples for
> "tricking" optimizers would be volatile loads or volatile asm
blocks
> (possibly without actual instructions inside).
>
> - Matthias
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170424/d3ca427f/attachment.html>