similar to: Representations of IR in the output of opt

Hi Eli, Unfortunately the differences remain, I do not observe a significant change in the output besides the fact that it's random. I noticed that running opt without options on the random file changes the order of references in the predecessors of basic blocks (sample below). Further invocations of opt are idempotent. I don't know of this information is stored in the bytecode file

Hi Mehdi, Thank you for mentioning this tool, I was looking for something like this. By default the analyzer produces identical output on both files, but a complete -dump shows that the storage order of the symbol table is different. This would explain why text files are not affected: the symbols are used directly in text form so there is no need for this table. I suppose that settles the

Hello again, > It may be desirable to sort the table before writing the bitcode out, > adding Peter to the thread for his opinion. Thanks for this! Now it seems I've been optimistic about this result. I have instrumented the test suite to check it on a wider amount of files and quickly discovered that it fails for larger optimization sequences. In particular, the default -O3 set

On Thu, Aug 1, 2019 at 6:38 PM JF Bastien <jfbastien at apple.com> wrote: > > > > > On Aug 1, 2019, at 9:20 AM, Alexander Potapenko <glider at google.com> wrote: > > > > On Thu, Aug 1, 2019 at 6:09 PM JF Bastien <jfbastien at apple.com> wrote: > >> > >> Hi Alexander, > >> > >> The code doesn’t compile. Could you send

There are two problems: 1. padding after union and call to q(), without LTO we can't remove that store. 2. shortcut which I have which ignores all instructions q() . this assume that memset to acpar.match, acpar.matchinfo also useful which is not true. I should be able to improve this case. On Thu, Aug 1, 2019 at 11:29 PM Vitaly Buka <vitalybuka at google.com> wrote: > On a first

I finally got back to this. It is a known and endemic issue that pops up from time to time. The issues I’m aware of so far are related to random sets being used where strict order is required. This may result in non-deterministic uselists issued by the bitcode/assembly writers. There is no great way to go about pro-active testing for this. Collecting the tests so far and running them as

Hi, This answer is a bit slow; I tried to look into the sequence details but 250 passes plus the complex bitcode of test suite examples makes this pretty hard. In the meantime I stumbled upon llvm-diff which abstracts away the most significant difference, namely instruction renaming. It also ignores function attributes so calling conventions are silently unified; but at least it gives empty

Hi, I reproduced the test on many individual files and got very variable results... it seems the computer's workload when running the test suite influenced the execution speed a lot more than standard deviation shows. I'll withdraw the performance claim until I can get consistent results (changed subject line), apologies for the confusion. What I can still show easily is that the

Hi Chris, Thanks for the detailed explanations. I have a few remaining questions: Am I correct that ScalarReplAggregates is hardly more expensive than Mem2Reg and therefore generally preferable? What would be the code quality implications of using "-dce -simplifycfg" instead of -adce? As far as I understand the algorithms involved, -dce would hardly ever miss a dead instruction if

Hello list, This is a follow-up from a question I asked last month. I'm evaluating the performance of two pass sequences that resemble (but are not) -O3. With -O3, -debug-pass=Structure prints several independent blocks that seem to represent several calls to opt. I focused on two of these blocks, say S1 and S2, and compared the following optimization methods: 1. Executing them

Hi Jeremy, Thank you for the reply. I understood. Regards, Shivappa > On 26-Apr-2016, at 12:01 am, Jeremy Allison <jra at samba.org> wrote: > >> On Mon, Apr 25, 2016 at 10:25:44AM +0530, Shivappa wrote: >> Hi list, >> >> When I back ported vulnerability patch to existing samba4.1.21, I'm facing many fileshare access functionality breaks. >>

Hi, I'm trying to autotune a good sequence of IR optimization passes and I seem to run into segfaults in opt (in LLVM5) with certain pass orderings. Is this expected behavior? If so, what would be the recommended way of determining pass dependencies so that I can encode them into the tuner? The test program can be found here: https://gist.github.com/kavon/92d153cdd54ce9b77162af3af47d4c95

It's been a while and I finally had the time to look into this. What I did was to build a custom AliasAnalysis pass, as Chris suggested, that returns AliasAnalysis::Mod for values passed to the sample function in the sret spot, and NoModRef for all other values. I'm also returning AliasAnalysis::AccessesArguments in the pass' getModRefBehavior methods. However, I haven't been

On Thu, Aug 1, 2019 at 6:09 PM JF Bastien <jfbastien at apple.com> wrote: > > Hi Alexander, > > The code doesn’t compile. Could you send a godbolt.org link that shows the issue? Sorry about that, here's the link: https://godbolt.org/z/-PinQP Lines 4 to 8 are initializing |acpar|. If I'm understanding correctly, the store to 8(%rsp) at line 7 can be removed because of the

On May 20, 2008, at 8:57 AM, David Greene wrote: > On Tuesday 20 May 2008 07:03, Nicolas Capens wrote: > >> 1) Does ScalarReplAggregates totally superscede >> PromoteMemoryToRegister? I > > Nope, they are different. Mem2Reg is really important if you want > register > allocation. Actually SROA does fully subsume Mem2Reg. It iterates between breaking up

Hi, I've been thinking about how to keep the line number with the llvm transform/Analysis passes. Basically, I agree with Chris's notes ( http://www.nondot.org/sabre/LLVMNotes/DebugInfoImprovements.txt), and I will follow his way to turn on the line number information when optimization enabled. Here is a detailed proposal: 1. Introduction At the time of this writing, LLVM's

CRAN (and crantastic) updates this week New packages ------------ * DCGL (1.0) Bao-Hong Liu http://crantastic.org/packages/DCGL Functions for basic differential coexpression analyses: gene filtering, link filtering, DCG (Differentially-Coexpressed Gene) identification and DCL (Differentially-Coexpressed Links) identification.Two algorithms,named DCP and DCe, are provided for

> On May 10, 2019, at 8:59 PM, Vitaly Buka via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Sorry for delay, I was busy with other stuff. > CTMark results. > > dse is the current DSE. > dsem is my experimental module level DSE. > dsem runs after dse, so it's additionally deleted stores. > > -O3 > dse - Number of stores deleted

Hi, Over the past six months, a MemorySSA-backed DSE implementation has been added to LLVM and it now covers almost all cases the existing DSE implementation does, plus adding a major new capability: eliminating stores across basic blocks. Thanks everyone involved with reviews, testing & patches! I think now would be a good time to start working towards switching to use MemorySSA-backed DSE

Below are the 4 cases out of which for the first 3 cases am able to understand the variation on total number of store inst. But when -gvn parameters is passed (in case 4) , why does the total number of strore Instruction present on the attached file increases (instead of decrease). Please explain considering that use of -reg2mem pass is mandatory. eg. clang -emit-llvm bzip.c -c -o bzip1.bc