[llvm-dev] opt with Polly doesn't find the passes
Frank Winter via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 3 08:49:44 PST 2016
On 02/03/2016 11:28 AM, Tobias Grosser wrote:
> On 02/03/2016 05:16 PM, Frank Winter wrote:
>>
>>
>> On 02/03/2016 11:06 AM, Tobias Grosser wrote:
>>> On 02/03/2016 04:46 PM, Frank Winter via llvm-dev wrote:
>>>>
>>>>
>>>> On 02/03/2016 10:41 AM, Tobias Grosser wrote:
>>>>> On 02/03/2016 04:37 PM, Frank Winter wrote:
>>>>>> Hi Tobias,
>>>>>>
>>>>>> I tried to invoke other passes and none of them are available, e.g.:
>>>>>>
>>>>>> ~/toolchain/install/llvm-3.8/bin/opt -load
>>>>>> ~/toolchain/install/llvm-3.8/lib/libPolly.so -polly-cleanup
>>>>>>
>>>>>> opt: Unknown command line argument '-polly-cleanup'. Try:
>>>>>> '/home/fwinter/toolchain/install/llvm-3.8/bin/opt -help'
>>>>>> opt: Did you mean '-polly-tiling'?
>>>>>
>>>>> I assume -polly-cleanup still shows in -help-hidden?
>>>>
>>>> No, it doesn't show. It never did. It looks to me that only the clang
>>>> options show in -help-hidden but not the passes. Can that be right?
>>>
>>> No, it can not. Interesting observation.
>>>
>>>>>> I am just shooting around hoping to get a clue what's going on...
>>>>>>
>>>>>> On thing.. I recall reading the polly documentation that there was
>>>>>> the
>>>>>> option to link opt statically with the polly library which I did not
>>>>>> select. But that's likely not the problem since a lot of polly
>>>>>> options
>>>>>> are apparently there.
>>>>>>
>>>>>> Out of ideas for now.
>>>>>
>>>>> This is surprising, indeed.
>>>>>
>>>>> The option is: LINK_POLLY_INTO_TOOLS:BOOL=ON. It might be worth giving
>>>>> it a try.
>>>>>
>>>>> What ubuntu version are you on precisely? I can try the 3.8 branch
>>>>> tonight myself.
>>>>
>>>> Ubuntu 14.04 LTS x86-64.
>>>
>>> Thanks. If you have cycles to try a LINK_POLLY_INTO_TOOLS:BOOL=ON build
>>> on your side, this would be great.
>>>
>>> Another data-point that might be of help is to just run the script at
>>> http://polly.llvm.org/get_started.html to install everything. This
>>> installs trunk the way it is tested and run by us day-to-day (myself
>>> using Ubuntu x86-64). This should be the most basic test that should
>>> work.
>>>
>>
>> The polly.sh script builds LLVM with static linkage and thus would
>> create a libPolly.a, right? This cannot be loaded into 'opt' nor would
>> 'opt' be linked with polly. I'd need a polly-enabled opt.
>
> By default it builds as a loadable module (not using
> LINK_POLLY_INTO_TOOLS), if this is what you mean by 'static linkage'.
>
By static linkage I mean building LLVM with -DBUILD_SHARED_LIBS="OFF"
(or omitting the option entirely, as I think that is the default). I
built the release_38 branch (llvm,clang and polly) with
cmake -G "Unix Makefiles" \
-DCMAKE_BUILD_TYPE=$CMAKE_BUILD_TYPE \
-DCMAKE_INSTALL_PREFIX=$CMAKE_INSTALL_PREFIX \
-DLLVM_TARGETS_TO_BUILD=$LLVM_TARGETS_TO_BUILD \
$SRC
and that created the 'libPolly.a' and polly was not linked into 'opt'.
What I am building at the minute is:
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm-trunk
svn co http://llvm.org/svn/llvm-project/polly/trunk llvm-trunk/tools/polly
svn co http://llvm.org/svn/llvm-project/cfe/trunk llvm-trunk/tools/clang
SRC=$HOME/svn/llvm-trunk
CMAKE_BUILD_TYPE="Debug"
CMAKE_INSTALL_PREFIX="$HOME/toolchain/install/llvm-trunk"
LLVM_TARGETS_TO_BUILD="X86"
cmake -G "Unix Makefiles" \
-DBUILD_SHARED_LIBS="ON" \
-DCMAKE_BUILD_TYPE=$CMAKE_BUILD_TYPE \
-DCMAKE_INSTALL_PREFIX=$CMAKE_INSTALL_PREFIX \
-DLLVM_TARGETS_TO_BUILD=$LLVM_TARGETS_TO_BUILD \
$SRC
make -j $number_of_CPUs
Thus, the only difference is that it uses trunk instead of release_38.
If the created 'opt' still doesn't find the polly passes I will go with
your suggestion and add the option LINK_POLLY_INTO_TOOLS=ON.
However, I have a strong feeling there's something haywire in the
release_38 branch regards this.
Best,
Frank
> Even when using LINK_POLLY_INTO_TOOLS=ON, Polly will be available in
> both clang and opt (as it will be linked into both).
>
>> I can try and build trunk (instead of the release_38 branch).
>
> This could give us at least another data point, as I don't really see
> what is going on here.
>
> Best,
> Tobias
More information about the llvm-dev
mailing list