running polly with dragonegg

[Sahasrabuddhe, Sameer]

Hi,

 

How does one enable polly when using dragonegg?

 

Is there some command-line syntax along the lines of “-fplugin-arg-dragonegg-something” that can be used to load LLVMPolly.so?

 

Sameer.

[Tobias Grosser]

On 07/11/2012 11:19 AM, Sahasrabuddhe, Sameer wrote:
> Hi,
>
> How does one enable polly when using dragonegg?
>
> Is there some command-line syntax along the lines of

> �-fplugin-arg-dragonegg-something� that can be used to load LLVMPolly.so?
>
> Sameer.

Hi Sameer,

I never tried. I copied Duncan. He should know if dragonegg allows to
load llvm modules.


For Duncan:
I use 'opt -O3 -load LLVMPolly.so -polly' to enable O3 + Polly
optimizations. I would hope that this could somehow be translated to a
dragonegg invocation.

The -polly could probably be passed by
-fplugin-arg-dragonegg-llvm-option=-polly. However, what about the -load
LLVMPolly.so? Is there an equivalent to ask gcc to load a shared object
file? (Nothing else is required, as static constructors should do the
registration to the LLVM pass list)

Tobi

[Duncan Sands]

Hi Tobias,

On 12/07/12 08:23, Tobias Grosser wrote:
> On 07/11/2012 11:19 AM, Sahasrabuddhe, Sameer wrote:
>> Hi,
>>
>> How does one enable polly when using dragonegg?
>>
>> Is there some command-line syntax along the lines of
>> �-fplugin-arg-dragonegg-something� that can be used to load LLVMPolly.so?
>>
>> Sameer.
>
> Hi Sameer,
>
> I never tried. I copied Duncan. He should know if dragonegg allows to load llvm
> modules.

no, there is no such functionality. I guess it could be added, so if you want
this please open a bugreport against dragonegg.

> For Duncan:
> I use 'opt -O3 -load LLVMPolly.so -polly' to enable O3 + Polly optimizations. I
> would hope that this could somehow be translated to a dragonegg invocation.

You can always do

gcc -fplugin=./dragonegg.so -O3 -flto -S -o -
-fplugin-arg-dragonegg-llvm-ir-optimize=0 | opt -O3 -load LLVMPolly.so -polly

Ciao, Duncan.

[Sahasrabuddhe, Sameer]

Duncan Sands wrote:

> > I never tried. I copied Duncan. He should know if dragonegg allows to
> > load llvm modules.
>
> no, there is no such functionality. I guess it could be added, so if you
> want this please open a bugreport against dragonegg.

> You can always do
> gcc -fplugin=./dragonegg.so -O3 -flto -S -o - -fplugin-arg-dragonegg-llvm-ir-optimize=0 | opt -O3 -load LLVMPolly.so -polly

A direct way to load LLVMPolly.so in dragonegg would be very useful, since invoking multiple commands does not play well with benchmark scripts. I'll file a bug against dragonegg.

Thanks,
Sameer.

[Sahasrabuddhe, Sameer]

Dragonegg can now load LLVM plugins, including Polly. Thanks, Duncan:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120709/146321.html

It can be used like this:

gcc -fplugin=./dragonegg.so -fplugin-arg-dragonegg-llvm-option=-load:LLVMPolly.so ...

But this leads to two more issues:

1. gcc complains about undefined symbols, since LLVM libraries need to be linked into LLVMPolly.so. I fixed this for now using a brute-force setting in the Makefile for the shared object:

LINK_COMPONENTS = all

This should be reduced to a list of the actual components required. Trying individual components such as "core" and "analysis" only results in more symbols reported undefined. Is there a blanket way to find all the required symbol definitions and somehow map them to the components that should be passed to llvm-config?

2. I suppose the polly optimizations should be enabled by passing yet another llvm-option to dragonegg, like so:

-fplugin-arg-dragonegg-llvm-option=-polly

But this results in an error:

cc1: Unknown command line argument '-polly'. Try: 'cc1 -help'
cc1: Did you mean '-load'?

Should this be treated as yet another enhancement in dragonegg?

Sameer.

[Tobias Grosser]

On 07/13/2012 06:59 AM, Sahasrabuddhe, Sameer wrote:
>
> Dragonegg can now load LLVM plugins, including Polly. Thanks, Duncan:
>
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120709/146321.html

Great. Thanks Duncan!!

> It can be used like this:
>
> gcc -fplugin=./dragonegg.so -fplugin-arg-dragonegg-llvm-option=-load:LLVMPolly.so ...
>
> But this leads to two more issues:
>
> 1. gcc complains about undefined symbols, since LLVM libraries need to be linked into LLVMPolly.so. I fixed this for now using a brute-force setting in the Makefile for the shared object:
>
> LINK_COMPONENTS = all
>
> This should be reduced to a list of the actual components required. Trying individual components such as "core" and "analysis" only results in more symbols reported undefined. Is there a blanket way to find all the required symbol definitions and somehow map them to the components that should be passed to llvm-config?

No idea how to get an exact list, but Polly works with opt and opt
requires the following components:

libLLVMBitReader.so
libLLVMBitWriter.so
libLLVMInstrumentation.so
libLLVMipo.so
libLLVMScalarOpts.so
libLLVMVectorize.so
libLLVMInstCombine.so
libLLVMTransformUtils.so
libLLVMipa.so
libLLVMAnalysis.so
libLLVMTarget.so
libLLVMAsmParser.so
libLLVMMC.so
libLLVMCore.so
libLLVMObject.so
libLLVMSupport.so

You may try reducing from here. Another thing that may help is to
include the header "include/llvm/LinkAllPasses.h". This was necessary for
clang to ensure all passes, relevant for Polly, are really linked in.

> 2. I suppose the polly optimizations should be enabled by passing yet another llvm-option to dragonegg, like so:
>
> -fplugin-arg-dragonegg-llvm-option=-polly
>
> But this results in an error:
>
> cc1: Unknown command line argument '-polly'. Try: 'cc1 -help'
> cc1: Did you mean '-load'?
>
> Should this be treated as yet another enhancement in dragonegg?

It might be possible, that the command line options are parsed before
polly is loaded. This will make dragonegg think the command line
options of polly are unknown.

Tobi

[Sahasrabuddhe, Sameer]

Tobias Grosser wrote:

> > cc1: Unknown command line argument '-polly'. Try: 'cc1 -help'
> > cc1: Did you mean '-load'?
> >
> > Should this be treated as yet another enhancement in dragonegg?
>
> It might be possible, that the command line options are parsed before
> polly is loaded. This will make dragonegg think the command line
> options of polly are unknown.

Indeed, that is the case. This will probably need a longer discussion on llvm-dev.

Sameer.

[Duncan Sands]

Hi Sameer,

> Dragonegg can now load LLVM plugins, including Polly. Thanks, Duncan:
>
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120709/146321.html
>
> It can be used like this:
>
> gcc -fplugin=./dragonegg.so -fplugin-arg-dragonegg-llvm-option=-load:LLVMPolly.so ...
>
> But this leads to two more issues:
>
> 1. gcc complains about undefined symbols, since LLVM libraries need to be linked into LLVMPolly.so. I fixed this for now using a brute-force setting in the Makefile for the shared object:
>
> LINK_COMPONENTS = all
>
> This should be reduced to a list of the actual components required. Trying individual components such as "core" and "analysis" only results in more symbols reported undefined. Is there a blanket way to find all the required symbol definitions and somehow map them to the components that should be passed to llvm-config?

the probable reason for this is that dragonegg is built with (hidden visibility
and) an explicit exports map, see exports.map. The only symbols it exports
are: plugin_is_GPL_compatible and plugin_init. Thus even if it is linked
against all kinds of LLVM libraries (which it is) the polly plugin won't be
able to access those routines because they are hidden inside the dragonegg.so
dynamic library. Try building dragonegg with this patch, does it help?

Index: Makefile
===================================================================
--- Makefile (revision 160120)
+++ Makefile (working copy)
@@ -36,14 +36,14 @@
QUIET:=@
endif

-COMMON_FLAGS=-Wall -Wextra -fvisibility=hidden
+COMMON_FLAGS=-Wall -Wextra #-fvisibility=hidden
CFLAGS+=$(COMMON_FLAGS) $(shell $(LLVM_CONFIG) --cflags)
CXXFLAGS+=$(COMMON_FLAGS) $(shell $(LLVM_CONFIG) --cxxflags)

ifeq ($(shell uname),Darwin)
LOADABLE_MODULE_OPTIONS=-bundle -undefined dynamic_lookup
else
-LOADABLE_MODULE_OPTIONS=-shared -Wl,-O1 -Wl,--version-script=$(TOP_DIR)/exports.map
+LOADABLE_MODULE_OPTIONS=-shared -Wl,-O1
#-Wl,--version-script=$(TOP_DIR)/exports.map
endif

GCC_PLUGIN_DIR:=$(shell $(GCC) -print-file-name=plugin)



The reason for only exporting these two symbols is that (1) it speeds the
loading of dragonegg.so and (2) allows link-time optimizers to do a lot of
good stuff when linking dragonegg.so.

> 2. I suppose the polly optimizations should be enabled by passing yet another llvm-option to dragonegg, like so:
>
> -fplugin-arg-dragonegg-llvm-option=-polly
>
> But this results in an error:
>
> cc1: Unknown command line argument '-polly'. Try: 'cc1 -help'
> cc1: Did you mean '-load'?
>
> Should this be treated as yet another enhancement in dragonegg?

I can reproduce this, but didn't get to the bottom of it yet. I think it is
related to pass registration: if the plugin registers a command line option
directly then that works fine. What doesn't work is if the option is the pass
name, -polly in this case.

Ciao, Duncan.

[Sahasrabuddhe, Sameer]

Duncan Sands wrote:

> the probable reason for this is that dragonegg is built with (hidden visibility
> and) an explicit exports map, see exports.map. The only symbols it exports
> are: plugin_is_GPL_compatible and plugin_init. Thus even if it is linked
> against all kinds of LLVM libraries (which it is) the polly plugin won't be
> able to access those routines because they are hidden inside the dragonegg.so
> dynamic library. Try building dragonegg with this patch, does it help?

I tried the patch. It still reports an undefined symbol, but a different one ... which means that LLVMPolly was able to pick up some symbols from dragonegg, but there are others which require additional libraries to be linked into LLVMPolly.so

Also, my earlier attempt of using "LINK_COMPONENTS=all" when building Polly ran into a problem with the opt binary. When I loaded the LLVMPolly.so in opt, it errorred out with the following message repeated for every command-line option:

opt: CommandLine Error: Argument 'info-output-file' defined more than once!

So, it seems I definitely need to find a smaller set of libraries to be linked into LLVMPolly.so

> I can reproduce this, but didn't get to the bottom of it yet. I think it is
> related to pass registration: if the plugin registers a command line option
> directly then that works fine. What doesn't work is if the option is the pass
> name, -polly in this case.

OK.

Sameer.

[Duncan Sands]

Hi Sameer,

>> the probable reason for this is that dragonegg is built with (hidden visibility
>> and) an explicit exports map, see exports.map. The only symbols it exports
>> are: plugin_is_GPL_compatible and plugin_init. Thus even if it is linked
>> against all kinds of LLVM libraries (which it is) the polly plugin won't be
>> able to access those routines because they are hidden inside the dragonegg.so
>> dynamic library. Try building dragonegg with this patch, does it help?
>
> I tried the patch. It still reports an undefined symbol, but a different one ... which means that LLVMPolly was able to pick up some symbols from dragonegg, but there are others which require additional libraries to be linked into LLVMPolly.so
>
> Also, my earlier attempt of using "LINK_COMPONENTS=all" when building Polly ran into a problem with the opt binary. When I loaded the LLVMPolly.so in opt, it errorred out with the following message repeated for every command-line option:
>
> opt: CommandLine Error: Argument 'info-output-file' defined more than once!

that's not surprising: if you link with some LLVM library that opt is already
linked with then you get two copies, each of which will run static constructors
at startup (doing things such as registering command line options) leading to
all kinds of badness, such as complaints that an option was already registered.
You could also add extra libraries to the dragonegg link line, here:


$(PLUGIN): $(PLUGIN_OBJECTS) $(TARGET_OBJECT) $(TARGET_UTIL)
@echo Linking $@
$(QUIET)$(CXX) -o $@ $(LOADABLE_MODULE_OPTIONS) $(CXXFLAGS) \
$(PLUGIN_OBJECTS) $(TARGET_OBJECT) $(shell $(LLVM_CONFIG) --libs \
analysis core ipo scalaropts target $(shell $(TARGET_UTIL) -p)) \
$(LD_OPTIONS)

^ add stuff to the "analysis core ipo scalaropts target" list.

Ciao, Duncan.

[Duncan Sands]

PS: as opt is linked with

bitreader bitwriter asmparser instrumentation scalaropts ipo vectorize

presumably your missing symbols are in one of those.

Ciao, Duncan.

[Tobias Grosser]

Yes, this is probably the way to go.

Tobi

[Duncan Sands]

Hi Sameer,

>> I can reproduce this, but didn't get to the bottom of it yet. I think it is
>> related to pass registration: if the plugin registers a command line option
>> directly then that works fine. What doesn't work is if the option is the pass
>> name, -polly in this case.

I notice that clang carefully loads all plugins before doing LLVM command line
parsing. I actually think it's a bug if this is required, but the way the pass
manager interacts with options is pretty baroque and I didn't work out yet just
why things work if all plugins are loaded before options parsing, and not when
plugins are loaded as part of options parsing.

Ciao, Duncan.

[Sahasrabuddhe, Sameer]

Hi Duncan and Tobias,

Here's the reduced set of components that work if I link
them into LLVMPolly.so (i.e., there are no errors about
undefined symbols):

bitwriter instrumentation vectorize analysis core ipo scalaropts target

opt always complains if I link any additional library into
Polly, even if it is just the "core" component. So unless
someone decide that this indicates a problem with opt,
we cannot think of linking these additional components
into the Polly shared object.

Instead it does not work if I link the same components into
dragonegg, while keeping all symbols visible. I get the
following undefined symbol: _ZN4llvm10RegionInfo2IDE.
But this is defined in libLLVMAnalaysis.a which definitely
gets included with a -lLLVMAnalysis when building
dragonegg.so (I checked with VERBOSE=1).

Sameer.

[Tobias Grosser]

On 07/16/2012 06:42 AM, Sahasrabuddhe, Sameer wrote:
> Hi Duncan and Tobias,
>
> Here's the reduced set of components that work if I link
> them into LLVMPolly.so (i.e., there are no errors about
> undefined symbols):
>
> bitwriter instrumentation vectorize analysis core ipo scalaropts target
>
> opt always complains if I link any additional library into
> Polly, even if it is just the "core" component. So unless
> someone decide that this indicates a problem with opt,
> we cannot think of linking these additional components
> into the Polly shared object.

No, we should really not link anything additional into polly. This will
not only fail with opt, but most probably also with clang.

> Instead it does not work if I link the same components into
> dragonegg, while keeping all symbols visible. I get the
> following undefined symbol: _ZN4llvm10RegionInfo2IDE.

OK. You are on the right way. Probably the compiler eliminates again
some symbols. You may want to include include/llvm/LinkAllPasses.h in
one of the dragonegg source files. This should help.

Cheers
Tobi

[Tobias Grosser]

On 07/13/2012 03:31 PM, Duncan Sands wrote:
> Hi Sameer,
>
>>> I can reproduce this, but didn't get to the bottom of it yet. I think
>>> it is
>>> related to pass registration: if the plugin registers a command line
>>> option
>>> directly then that works fine. What doesn't work is if the option is
>>> the pass
>>> name, -polly in this case.

-polly is not a pass name, but an option that makes LLVMPolly schedule
the polly passes at -O3. So loading polly should work without any option
specified.

> I notice that clang carefully loads all plugins before doing LLVM
> command line
> parsing. I actually think it's a bug if this is required, but the way
> the pass
> manager interacts with options is pretty baroque and I didn't work out
> yet just
> why things work if all plugins are loaded before options parsing, and
> not when
> plugins are loaded as part of options parsing.

I think clang is a different case (as it does some special stuff). For
opt and hopefully also dragonegg the following should hold:

Plugin options can be used after having loaded the plugin. This means:

## Works correctly ##
$opt -load LLVMPolly.so -O3 single_loop.ll -polly

## Does not work ##
$opt -polly -load LLVMPolly.so -O3 single_loop.ll
opt: Unknown command line argument '-polly'. Try:
'/home/grosser/Projekte/polly/build_clang/bin/opt -help'
opt: Did you mean '-no-aa'?

Cheers
Tobi

[Sameer Sahasrabuddhe]

On Mon, 16 Jul 2012 09:34:34 +0200
Tobias Grosser <tob...@grosser.es> wrote:

> OK. You are on the right way. Probably the compiler eliminates again
> some symbols. You may want to include include/llvm/LinkAllPasses.h in
> one of the dragonegg source files. This should help.

Ok, everything works now. I made the following modifications:

1. Made the symbols in dragonegg visible.
2. Added some additional LLVM components as mentioned earlier.
3. Also added the LinkAllPasses.h header to one of the source files.

Note that all three steps are needed.

Now everything works ... you can load polly and the "-polly" option is
also correctly handled. Can't understand why it does not work if the
LLVM components were linked into the Polly plugin instead of dragonegg.

Attached a patch with the relevant changes.

Sameer.

[Tobias Grosser]

This is great! Sameer and Duncan, thanks a lot for making this work.

Duncan: Can this be committed upstream in some way?

Tobi

[Sahasrabuddhe, Sameer]

Hi all,

Dragonegg now allows one to load and enable Polly (this used to error out earlier):

http://llvm.org/bugs/show_bug.cgi?id=13379

To use it, you need the latest dragonegg source, and build it with an additional build option:

$ cd dragonegg
$ ENABLE_LLVM_PLUGINS=1 LLVM_CONFIG=... GCC=... make

$ cd helloworld
$ gcc -O3 -fplugin=/path/to/dragonegg.so -fplugin-arg-dragonegg-llvm-option=-load:/path/to/llvm/lib/LLVMPolly.so -fplugin-arg-dragonegg-llvm-option=-polly hello.c

Sameer.