similar to: [LLVMdev] Jump Theading/GVN bug - moving discussion to llvm-dev

Whatever we end up deciding, I think we do need to preserve the ability of a language frontend to generate complete garbage in the form of unreachable code. If we decide to move in the direction of disallowing the production of unreachable code, we need to write a canonicalization pass that runs first thing in the pipeline. A frontend should be able to produce unreachable code. This

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Katya Romanova" <Katya_Romanova at playstation.sony.com>, "Nick Lewycky" <nlewycky at google.com> > Cc: llvmdev at cs.uiuc.edu, "Philip Reames" <listmail at philipreames.com>, "Hal Finkel" <hfinkel at anl.gov>,

On 24 February 2015 at 02:05, Chandler Carruth <chandlerc at google.com> wrote: > Will try to reply to the larger thread again soon, but a quick reply on a > bit of a tangent... > > On Mon, Feb 23, 2015 at 8:45 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >> 2. Should unreachable code be allowed to contain nonsense (like >> instructions that depend on

Hello, I have several low priority UBSan questions... (1) Is there a way for UBSan to print its output to a file that the user specified (e.g. via option) instead of dumping everything on stderr? (2) Out of curiosity, why is the name of the option for printing the stacktrace spelled "UBSAN_OPTIONS=print_stacktrace=1", though the allowed value is 1? Since the only one value is

Hello, LLVM generates two additional instructions for 128->256 bit typecasts (e.g. _mm256_castsi128_si256()) to clear out the upper 128 bits of YMM register corresponding to source XMM register. vxorps xmm2,xmm2,xmm2 vinsertf128 ymm0,ymm2,xmm0,0x0 Most of the industry-standard C/C++ compilers (GCC, Intel's compiler, Visual Studio compiler) don't generate any extra moves

> Programmers don't usually write code like this directly, but it is common > for it to happen as a result of the expansion of macros or inline functions. > You would not want to require that a compiler front end *not* produce this. I meant to say that whatever mechanism we use to track dead blocks that may exhibit edge-cases of SSA def-use behavior does *not* need to be clever

> Handling unreachable code is annoying. I agree. However, its important to > characterize how annoying. Most code is not unreachable, and we're > (obviously) fine just bailing on such crazy code paths. So in practice the > common cost is keeping a local set to detect cycles in the graph where we > aren't expecting them. We are essentially always traversing a linked list

> Maybe. > My view is the ideal is either no-unreachable code, or unreachable blocks > only contain terminators. I am definitely happy with both. What worries me is introducing a special dominance rule for unreachable blocks. >> I don't think that rejecting >> >> %a = getelementptr inbounds i8* %a, i64 1 >> >> but accepting >> >> %a =

On 25 February 2015 at 10:58, Daniel Berlin <dberlin at dberlin.org> wrote: > > > On Wed, Feb 25, 2015 at 6:26 AM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: >> >> > Maybe. >> > My view is the ideal is either no-unreachable code, or unreachable >> > blocks >> > only contain terminators. >> >> I am

>> define void @f() { >> bb0: >> ret void >> bb1: >> %a = getelementptr inbounds i8* %b, i64 1 >> ret void >> bb2: >> %b = getelementptr inbounds i8* %a, i64 1 >> ret void >> } >> >> Since bb1 dominates bb2 and bb2 dominates bb1, no? > > I think this a great example of how our current definition is

On 02/25/2015 10:41 AM, Rafael Espíndola wrote: >>> all the zero paths from entry to %a pass by %b. >> >> That is a graph-wise definition, sure. >> So, this is an interesting definition, and maybe this is part of the source >> of the problem. >> >> For SSA, at least GCC requires that both "definition block dominates use >> block" (which

>> all the zero paths from entry to %a pass by %b. > > > That is a graph-wise definition, sure. > So, this is an interesting definition, and maybe this is part of the source > of the problem. > > For SSA, at least GCC requires that both "definition block dominates use > block" (which would be true here), *and* > that "definition appears before use in

See attached some quick slides (backup from the dev meeting talk) about the pass pipeline. -- Mehdi Le mer. 11 avr. 2018 à 12:18, Mehdi AMINI <joker.eph at gmail.com> a écrit : > > > Le mer. 11 avr. 2018 à 11:20, <katya.romanova at sony.com> a écrit : > >> >> >> >> >> *From:* Mehdi AMINI <joker.eph at gmail.com> >> *Sent:*

Hi Mehdi, Awesome! It’s a very clear design. The only question left is which pipeline to choose for unified compile-phase optimization pipeline. - ThinLTO compile-phase pipeline? It might very negatively affect compile-time and the memory footprint for FullLTO link-phase. That was the reason why so many optimization were moved from the link-phase to the parallel compile-phase for FullLTO

From: Mehdi AMINI <joker.eph at gmail.com> Sent: Tuesday, April 10, 2018 11:53 PM To: Romanova, Katya <katya.romanova at sony.com> Cc: David Blaikie <dblaikie at gmail.com>; Teresa Johnson <tejohnson at google.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] exploring possibilities for unifying ThinLTO and FullLTO frontend + initial optimization

On Tue, Apr 10, 2018 at 11:52 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > Le mar. 10 avr. 2018 à 23:18, <katya.romanova at sony.com> a écrit : > >> Hi Mehdi, >> >> >> >> Awesome! It’s a very clear design. The only question left is which >> pipeline to choose for unified compile-phase optimization pipeline. >> >> -

Le mar. 10 avr. 2018 à 23:18, <katya.romanova at sony.com> a écrit : > Hi Mehdi, > > > > Awesome! It’s a very clear design. The only question left is which > pipeline to choose for unified compile-phase optimization pipeline. > > - ThinLTO compile-phase pipeline? It might very negatively affect > compile-time and the memory footprint for FullLTO link-phase.

Hi Peter, Thank you for the clarification ☺. I’m sure you have a very good understanding of how much efforts it will take to write a patch for legacy C LTO to implement caching the same way it’s done in new C++ LTO API. How easy/difficult do you think it will be (very roughly, in LOC)? Do you anticipate that a lot of existing legacy C LTO infrastructure will have to be rewritten? Could this also

On Mon, Mar 26, 2018 at 7:34 PM, <katya.romanova at sony.com> wrote: > Hi Peter, > > > > Thank you for the clarification J. > > > > I’m sure you have a very good understanding of how much efforts it will > take to write a patch for legacy C LTO to implement caching the same way > it’s done in new C++ LTO API. How easy/difficult do you think it will be >

Hi, It is non trivial to recompute summaries (which is why we have summaries in the bitcode in the first place by the way), because bitcode is expensive to load. I think shipping two different variant of the bitcode, one with and one without summaries isn't providing much benefit while complicating the flow. We could achieve what you're looking for by revisiting the flow a little. I