[LLVMdev] doxygen build fails

[Vlad Krylov]

Hi

I've tried to get doxygen documentation by configuring with
--enable-doxygen. Then 'make install' has been interrupted with
message "error: configuration file
/media/data/virtual/share/gsoc/build/docs/doxygen.cfg not found!".

mikem, why did you remove a line "AC_CONFIG_FILES([docs/doxygen.cfg])"
in autoconf/configure.ac [1] ?

I've restored this line. Now 'make install' is ok and doxygen is generated.

I've done patсh by 'git diff'. If it's not acceptable, please inform me.

[1] https://llvm.org/viewvc/llvm-project/llvm/trunk/autoconf/configure.ac?r1=102719&r2=103213&sortby=log

5 апреля 2011 г. 16:39 пользователь Tobias Grosser
<grosser at fim.uni-passau.de> написал:
> On 04/04/2011 12:23 AM, Vlad Krylov wrote:
>>
>> Hi.
>
> Hi Vlad,
>
> first of all it seems the conflict with raghesh was already solved. Nice.
>
> Regarding your draft. It looks like a reasonable first version, but it
> obviously needs to be extended for the final application. I would also
> recommend to install Polly and try to find the first test cases that cannot
> be handled.
>
> Some comments to your work plan:
>
>> My plan would be:
>>
>> 1w Study sources of Polly and LLVM docs relating to analysis
>
> You should do this for your application. ;-) At least you should start. Did
> you already find the place in the scopdetection where we check if an access
> function is valid?
>
>> 2w Create tests which demonstrate problems with NSW/NUW
>
> I think it would be good to show at least one test case already in the
> application.
>
>> 3-4w Fix the handling of wrap overflows.
>
> What does need to be fixed? What is wrong at the moment? (there is obviously
> a problem as stated on the Polly wiki, but I believe it would be good to
> explain this to the audience. It will also be good for you to understand the
> actual problem in the code (In case you need help feel free to ask)).
>
>> 5w Complete middle term paperwork.
>
> What is middle term paperwork?
>
>> 6w Create tests for each of cases which are not currently optimized
>> (e.g. have min/max, sext/zext, trunc or unsigned comparisons in the loop
>> bounds or memory accesses).
>
> Again. Some test cases could already be shown in the application.
>
>> 7w Learn how optimization process work for this examples.
>
> I do not think you need to optimize here anything. It should be sufficient
> to recognize code that includes such statements and transform them into a
> polyhedral represenation. Optimizers like Pluto will automatically calculate
> the relevant optimizations, if you generate a correct polyhedral
> representation.
>
>> 8-10w Enable tests one by one.
>
> By 'Enable tests' do you mean implementing support for min/max ..
> expressions?
>
>> 11w Estimate SPEC 264ref performnace improvement (yes, I have access to
>> one).
>
> What do you plan to measure exactly? Runtime performance?
>
> I think another very interesting thing would be an analysis that shows how
> much of the hot loops we can optimize. You can use such an analysis also to
> estimate the possible speedups we can achieve. Andreas (CCed) may be able to
> help you with some performance measurements he has already taken.
>
>> 12w Complete paperwork.
>
> What is paperwork? And why does is take a week?
>
> I also think it would be great if you could keep track of the code coverage
> improvement you achieve on the llvm testsuite.
>
> I added a lot of remarks, mainly because I am really interested in such a
> project. Please feel free to ask back if you need any help.
>
> Cheers
> Tobi
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doxygen.patch
Type: text/x-patch
Size: 1317 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110405/7c8f1385/attachment.bin>