similar to: [INFO] Buildbot llvm-docs failure

Hello Djordje, Vedant, Thanks a lot for sharing information. I have a doubt, please consider the following simple test case- #include <iostream> int func(int* ptr){ std::cout << *ptr; return *ptr + 5; } int main(int argc, char** argv){ int a = 4; int* ptr_a = &a; int b = func(ptr_a); return 0; } commandline used -- bash$ clang++

> Could you please describe what is the benefit of that? Currently there are two ways to provide DISPFlagDefinition, via bool and SPFlag, I would like to make it only via SPFlags, it will be NFC and it will make the changes in parser simpler for moving five flags from from DIFlags to DISPFlags. Currently parser checks the presence of SPFlags to see if the definition is present in bool or spflag

Yes, removing the support for isLocal, isDefinition fields completely from ll files, currently the LLParser still parses it. I want to remove it and update the all the ll files which still uses it. Also the metadata read will support old format, no changes in that. so if ll file has isLocal and isDefinition it will result in parser error. But the bitcode read will work as usual. - Chirag.

> On Sep 10, 2019, at 6:15 AM, Djordje Todorovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sourabh, > > Support for call-site related DWARF 5 tag/attributes is implemented very late, in the LLVM middle-end. > Please note that there is also the IR-level flag (DIFlagAllCallsDescribed) that lowers to > the DW_AT_call_all_calls. > > There is also

Hi Vedant, Thanks a lot for your comments! >It looks like a lot of the new infrastructure introduced here <https://github.com/djolertrk/llvm-di-checker/commit/9d26ac2557c584f6cf82ac5535fc47f8bd267a27> consists of logic copied from the debugify implementation. Why is introducing a new pair of passes better than extending the ones we have? The core infrastructure needed to track

Hi Djordje, On Wed, Sep 9, 2020 at 7:52 AM Djordje Todorovic <Djordje.Todorovic at syrmia.com> wrote: > Using entry-values ('callee' side of the feature) is not enough in any case. It is always connected to the call-site-param (function arguments but we call it call-site-params; 'caller' side of the feature) debug info. I believe that there are call-site-params that could

Hi David, Thanks for your comments! I just want to add that I think it would neat if the entry values could map into multi-location dbg.values and DBG_VALUEs that are being proposed on this list. For example, if we have: int local = param1 + param2 + 123; I think it would be good if we would be able to to represent the four different permutations of the values of the parameters being

On 08/01/2018 19:16, Matthias Braun wrote: > I believe the results of the docu generation can be found here: > > http://lists.llvm.org/pipermail/www-scripts/2018-January/thread.html > > (though a nice improvement for the future would be to make this into a > buildbot or jenkins job so people would get direct blame mails) > Thanks Matthias. I had a look at the error

I will get this fixed today. Sorry I have been dealing with some family stuff yesterday. -Tanya > On Jan 9, 2018, at 9:58 AM, Florian Hahn <florian.hahn at arm.com> wrote: > > > >> On 08/01/2018 19:16, Matthias Braun wrote: >> I believe the results of the docu generation can be found here: >>

Hi all, The debug entry values feature introduces new DWARF symbols (tags, attributes, operations) on caller (call site) as well as on callee side; and the intention is to improve debugging user experience by using the functionality (especially in “optimized” code by turning “<optimized_out>” values into real values). The call site information includes info about call itself (described with

Hi, Thanks you all for the collaboration! :) Paul, > This is not how tuning-controlled features are supposed to work. I will comment on the review. I see, I am working on addressing the comments from the [1]. I will update the diff asap. Thanks. Vedant, There are no entry values generated at -O0 level, but I will add a test case for it. Thanks. Best regards, Djordje On 8.2.20. 02:41,

Last night, I triggered a buildbot error after my most recent commit. That one was totally on me as the warning did pop up while generating the docs site locally using the sphinx-build command (confirmed this afternoon). I just checked in a commit to resolve the error but now it appears I've triggered a different buildbot error? This error did not come up when I built the site locally to test

Hi Djordje, [Late reply as I was away, alas], For the example in https://reviews.llvm.org/D85012 , I'm not sure that just using an entry value is correct. The reason why the dbg.values for arguments are set to undef is not because the value can't be described, it's because deadargelim changes all the call sites to pass in 'undef', which I believe makes the value unrecoverable

Hi, I am sharing the proposal [0] which gives a brief introduction for the implementation of the LLVM DI Checker utility. On a very high level, it is a pair of LLVM (IR) Passes that check the preservation of the original debug info in the optimizations. There are options controlling the passes, that could be invoked from ``clang`` as well as from ``opt`` level. By testing the utility on the

Anyone knows what this error message is? WARNING: search index couldn't be loaded, but not all documents will be built: the index will be incomplete. It's been frequent in: http://lab.llvm.org:8011/builders/llvm-sphinx-docs but after the commit that contains docs pass, it goes back to green. This looks like some system issue... cheers, --renato

Hi, it seems like http://llvm.org/docs/ stopped updating around 2018-01-03 (the footer at http://llvm.org/docs/ says `Last updated on 2018-01-03`). I've committed a new page [1], on the 4th but it does not show up yet. I could not find any public logs of the doc-builder. It would be great it someone could have a look. Cheers, Florian [1]

On Tue, Feb 12, 2019 at 11:05 AM Jonas Devlieghere via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, Feb 12, 2019 at 10:54 AM Kostya Serebryany <kcc at google.com> wrote: > >> >> >> On Tue, Feb 12, 2019 at 10:45 AM Jonas Devlieghere <jonas at devlieghere.com> >> wrote: >> >>> Hi Kostya, >>> >>> I remember

Hi All, I've been working on some documentation changes for GlobalISel and it looks like they aren't being reflected on llvm.org <http://llvm.org/>. In particular, the change I landed on the 25th Oct (https://github.com/llvm/llvm-project/commit/feab0334f57d) hasn't appeared yet. This commit changed the 'Global Instruction Selection' link at

Hi Tanya, Last time I noticed a problem with clang-tools-extra docs you could help solving them. If someone else is taking care of this part of the infrastructure now, please redirect appropriately. It looks like docs generated from rst (for LLVM, Clang and clang-tools-extra) don't get updated at the moment. They stopped updating somewhere between r353327

On Tue, Feb 12, 2019 at 10:45 AM Jonas Devlieghere <jonas at devlieghere.com> wrote: > Hi Kostya, > > I remember seeing this in the past. IIRC it was sufficient to install > recommonmark with `pip install recommonmark`. > installing this on my machine won't help the bots that build the docs, right? > > Cheers, > Jonas > > On Tue, Feb 12, 2019 at 10:17 AM