similar to: [LLVMdev] question about the alignment of the .text section

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

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:*

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

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. >> >> -

Hi Teresa, Thank you so much for your reply! I am on vacation until the end of this week and on EuroLLVM next week, so I have to apologize in advance that my replies are delayed. >>Right - see my reply on this from last night, at the very least the ThinLTO importing thresholds will need retuning if we will >>perform optimizations like unrolling/vectorization/etc that tend to

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 Steven and Peter, I think we resolved all the misunderstanding/concerns that we had with the proposal and decided that we don’t have to implement heavy-weight synchronization solutions (such as read-write locks, etc). Lightweight solution is expected to work on MacOS and Windows (however, there might be issues with Windows supporting non-NTFS file systems). There are two options for the

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

Le mer. 11 avr. 2018 à 11:20, <katya.romanova at sony.com> a écrit : > > > > > *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

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

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

Hello, I encountered a problem triggered by Jump-Threading optimization. This pass is creating an unreachable block with an instruction that is not well formed, which then causes the subsequent GVN pass to enter an infinite loop. I have submitted a bug report and proposed fix to llvm-commits. This bug opened a can of worms. I was asked to move the discussion to llvm-dev to reach for a wider

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

Hi David, Thank you so much for your reply! >> You're dealing with a situation where you are shipped BC files offline and then do one, or multiple builds with these BC files? Yes, that’s exactly the case. >> If the scenario was more like a naive build: Multiple BC files generated on a single (multi-core/threaded) machine (but some Thin, some >> Full) & then fed to the

> On Mar 26, 2018, at 6:03 PM, katya.romanova at sony.com wrote: > > Hi Steven, > Look at my replies inline (below your comments). > Katya. > > From: stevenwu at apple.com <mailto:stevenwu at apple.com> <stevenwu at apple.com <mailto:stevenwu at apple.com>> > Sent: Thursday, March 22, 2018 4:46 PM > To: Romanova, Katya <katya.romanova at sony.com

On Mon, Mar 26, 2018 at 6:03 PM, <katya.romanova at sony.com> wrote: > Hi Steven, > > Look at my replies inline (below your comments). > > Katya. > > > > *From:* stevenwu at apple.com <stevenwu at apple.com> > *Sent:* Thursday, March 22, 2018 4:46 PM > *To:* Romanova, Katya <katya.romanova at sony.com> > *Cc:* Teresa Johnson <tejohnson at

Hi Steven, Look at my replies inline (below your comments). Katya. From: stevenwu at apple.com <stevenwu at apple.com> Sent: Thursday, March 22, 2018 4:46 PM To: Romanova, Katya <katya.romanova at sony.com> Cc: Teresa Johnson <tejohnson at google.com>; Mehdi AMINI <joker.eph at gmail.com>; Rafael Avila de Espindola <rafael.espindola at gmail.com>; Peter Collingbourne

From: stevenwu at apple.com <stevenwu at apple.com> Sent: Monday, March 26, 2018 11:58 PM To: Mehdi AMINI <joker.eph at gmail.com> Cc: Romanova, Katya <katya.romanova at sony.com>; Teresa Johnson <tejohnson at google.com>; Rafael Espíndola <rafael.espindola at gmail.com>; Peter Collingbourne <peter at pcc.me.uk>; Hans Wennborg <hans at chromium.org>; Reid