Page MenuHomePhabricator

mehdi_amini (Mehdi AMINI)
User

Projects

User does not belong to any projects.

User Details

User Since
Apr 30 2013, 5:34 PM (312 w, 1 d)

Recent Activity

Yesterday

mehdi_amini added inline comments to D61022: [ThinLTO] Pass down opt level to LTO backend and handle -O0 LTO in new PM.
Tue, Apr 23, 11:07 AM · Restricted Project, Restricted Project
mehdi_amini added inline comments to D61022: [ThinLTO] Pass down opt level to LTO backend and handle -O0 LTO in new PM.
Tue, Apr 23, 9:19 AM · Restricted Project, Restricted Project

Wed, Apr 17

mehdi_amini committed rL358606: Add slides for the 2019 EuroLLVM Tutorial on MLIR.
Add slides for the 2019 EuroLLVM Tutorial on MLIR
Wed, Apr 17, 11:42 AM

Thu, Apr 11

mehdi_amini added inline comments to D60495: Load balancing for LTO.
Thu, Apr 11, 5:51 PM · Restricted Project

Mon, Apr 8

mehdi_amini accepted D60399: [CMake] Replace LLVM_ENABLE_CXX1Y and friends with LLVM_CXX_STD.
Mon, Apr 8, 2:06 AM · Restricted Project

Tue, Mar 26

mehdi_amini added a comment to D59837: Add "git llvm revert" subcommand.

Looks great! Thanks.

Tue, Mar 26, 9:54 PM · Restricted Project

Mar 21 2019

mehdi_amini committed rL356732: Add a new entry in the Open Projects webpages for "Improving Clang diagnostics".
Add a new entry in the Open Projects webpages for "Improving Clang diagnostics"
Mar 21 2019, 8:55 PM

Mar 12 2019

mehdi_amini added inline comments to D59251: [Documentation] Proposal for plan to change variable names.
Mar 12 2019, 3:33 PM · Restricted Project

Mar 11 2019

mehdi_amini updated subscribers of D31739: Add markup for libc++ dylib availability.
Mar 11 2019, 9:14 AM · Restricted Project

Mar 9 2019

mehdi_amini accepted D59161: [git-llvm] Only use --force-interactive when supported.
Mar 9 2019, 4:45 PM · Restricted Project

Feb 25 2019

mehdi_amini accepted D58631: [ThinLTO] Use defined node and edge order when dumping DOT files.

Thanks!

Feb 25 2019, 9:30 AM · Restricted Project

Feb 24 2019

mehdi_amini added a comment to D58391: [TailCallElim] Add tailcall elimination pass to LTO Pipelines.

What's the general state of the LTO pipeline at this point? PassManagerBuilder::addLTOOptimizationPasses is adding passes in a really weird order (in particular, the placement of the inliner is really strange). Has anyone looked at it recently? Would it be worth killing it off in favor of the ThinLTO pipeline just so we don't have to maintain it?

The reason they don't use the same pipeline is that it would be too expensive for regular LTO mode which is serial. ThinLTO can use a more aggressive post-link pipeline due to the parallelism. Mehdi did some measurements a couple years ago and found that using the ThinLTO pipeline for regular LTO increases the compile time in that mode significantly.

Feb 24 2019, 4:37 PM · Restricted Project

Feb 19 2019

mehdi_amini added a comment to D58420: docs/GithubMove.rst: Remove obsolete information.

LGTM, but you should probably wait to hear from someone else as well

Feb 19 2019, 7:01 PM · Restricted Project
mehdi_amini added a comment to D58384: [ThinLTO] Fix test with reverse-iteration.

Summary clusters, nodes and edges are retrieved from DenseMap with arbitrary order, which doesn't make result DOT file invalid.
Reverse iteration just exposes test issues.

Feb 19 2019, 9:37 AM · Restricted Project
mehdi_amini added a comment to D58384: [ThinLTO] Fix test with reverse-iteration.

Is it expected that the test output is sensitive to reverse iteration?
It sounds to me more like an issue with the code than with how the test is expressed.

Feb 19 2019, 8:23 AM · Restricted Project

Feb 13 2019

mehdi_amini added a comment to D58157: Stop enabling clang-tools-extra automatically when clang is in LLVM_ENABLE_PROJECTS.
In D58157#1397302, @rnk wrote:

It'd still be nice to identify the end goal with most cfe people (i.e. even if you land this right now, discussing the desired layout in the monorepo)

I sent off http://lists.llvm.org/pipermail/cfe-dev/2019-February/061290.html, so the larger community is aware of this change. I don't have much to add to a larger discussion about possible code reorganizations, but I suppose folks may come forward to express their opinions.

Feb 13 2019, 3:52 PM · Restricted Project
mehdi_amini added a comment to D58157: Stop enabling clang-tools-extra automatically when clang is in LLVM_ENABLE_PROJECTS.
In D58157#1396824, @rnk wrote:
And, this change really just keeps us at parity with what we had with svn. We can always revisit the decision to merge the clang tools into clang. This particular change just gives us more options, today.
Feb 13 2019, 3:02 PM · Restricted Project
mehdi_amini added a comment to D58157: Stop enabling clang-tools-extra automatically when clang is in LLVM_ENABLE_PROJECTS.
In D58157#1395716, @rnk wrote:

I think we have consensus,

Based on three comments in a revision? Seems strange to me.
I don't really care about this, so do whatever you want, but I would expect that "consensus" means an actual wider discussion (i.e. llvm-dev + cfe-dev).

Please cite said discussion for when you added this, as requested above.

Feb 13 2019, 2:58 PM · Restricted Project

Feb 12 2019

mehdi_amini added a comment to D58157: Stop enabling clang-tools-extra automatically when clang is in LLVM_ENABLE_PROJECTS.
In D58157#1395716, @rnk wrote:

I think we have consensus,

Feb 12 2019, 8:52 PM · Restricted Project
mehdi_amini added a comment to D58157: Stop enabling clang-tools-extra automatically when clang is in LLVM_ENABLE_PROJECTS.

What is the motivation to change this now?

Feb 12 2019, 5:11 PM · Restricted Project

Feb 6 2019

mehdi_amini added a comment to D57535: [CMake] Use LLVM_ENABLE_PROJECTS as the "single source" of truth when used..

Could we sanitize the list of LLVM_ENABLE_PROJECTS and error for unknown entries?

Feb 6 2019, 2:16 PM · Restricted Project

Feb 5 2019

mehdi_amini added a comment to D56485: Always compare C++ typeinfo (based on libstdc++ implementation)..

@dexonsmith: I'm not sure why a new differential should be created? I updated reviewers in this one.

Feb 5 2019, 9:38 AM

Feb 2 2019

mehdi_amini added a comment to D57535: [CMake] Use LLVM_ENABLE_PROJECTS as the "single source" of truth when used..

Thanks for fixing this!

Feb 2 2019, 1:01 PM · Restricted Project

Jan 30 2019

mehdi_amini added a comment to D57422: [LTO] Set CGOptLevel in LTO config..
In D57422#1376600, @pcc wrote:

Can I ask why you don't want --lto-O0 to set CGOptLevel to None?

The brief answer is: --lto-O0 means no cross-module optimizations,

Jan 30 2019, 2:19 PM

Jan 29 2019

mehdi_amini added a comment to D57330: Adjust documentation for git migration..

You can avoid the git status pollution by adding the build directory to .git/info/exclude.

Jan 29 2019, 1:21 PM
mehdi_amini added a comment to D57330: Adjust documentation for git migration..

This is not an full out-of-source build, since the build folder is still a subfolder of the repo root

Jan 29 2019, 11:48 AM

Jan 28 2019

mehdi_amini added a comment to D57330: Adjust documentation for git migration..

LGTM, but for one comment that requires a fix I believe (lld on Windows)

Jan 28 2019, 9:47 PM

Jan 27 2019

mehdi_amini accepted D57206: [ThinLTO] Add option to dump per-module summary dot graph.
Jan 27 2019, 10:36 AM
mehdi_amini added inline comments to D57203: [ThinLTO] Refine reachability check to fix compile time increase.
Jan 27 2019, 10:31 AM

Jan 26 2019

mehdi_amini added inline comments to D57203: [ThinLTO] Refine reachability check to fix compile time increase.
Jan 26 2019, 5:10 PM

Jan 24 2019

mehdi_amini added inline comments to D57206: [ThinLTO] Add option to dump per-module summary dot graph.
Jan 24 2019, 8:53 PM
mehdi_amini added inline comments to D57203: [ThinLTO] Refine reachability check to fix compile time increase.
Jan 24 2019, 8:38 PM

Jan 18 2019

mehdi_amini updated subscribers of D56485: Always compare C++ typeinfo (based on libstdc++ implementation)..

@pcc: Since this impacts CFI, can you say if the perf impact is acceptable on your end?
@mehdi_amini: Same Qs, but about macOS

Jan 18 2019, 8:17 AM

Jan 16 2019

mehdi_amini added a comment to D56799: [NFC] Factor out + document build requirements.

LGTM.

Jan 16 2019, 11:40 AM · Restricted Project
mehdi_amini added a comment to D47073: Document and Enforce new Host Compiler Policy.
In D47073#1360077, @jfb wrote:

That's incorrect. I don't care what the policy is as long as it's sane. 3 years was proposed on the RFC, we went with it. Then nuance was asked for on this review, we went with it. Then it was asked that time was made a soft constraint, we went with it. Then more bikeshed happened.

Jan 16 2019, 10:23 AM

Jan 15 2019

mehdi_amini added a comment to D47073: Document and Enforce new Host Compiler Policy.

I can't add much more than what @jyknight wrote here: https://reviews.llvm.org/D47073#1358937 ; this summarize perfectly my view of the situation.

Jan 15 2019, 10:39 PM
mehdi_amini added inline comments to D56770: Alternative wording/organization for the new policy.
Jan 15 2019, 9:40 PM
mehdi_amini added a comment to D47073: Document and Enforce new Host Compiler Policy.

I don't want to give the impression I'm stalling this just for the sake of being difficult, and since it is easier to talk "with code" I quickly wrote this: https://reviews.llvm.org/D56770 . This *not* a patch intended to be submitted, it is just a stripped-down version of how I'd phrase/structure it intended to support my arguments in this thread. Note that I would intentionally left out any compiler minimum bump out of the policy upgrade change, as these are conceptually separate change anyway.

Jan 15 2019, 8:46 PM
mehdi_amini updated the summary of D56770: Alternative wording/organization for the new policy.
Jan 15 2019, 8:46 PM
mehdi_amini added inline comments to D56770: Alternative wording/organization for the new policy.
Jan 15 2019, 8:41 PM
mehdi_amini created D56770: Alternative wording/organization for the new policy.
Jan 15 2019, 8:37 PM
mehdi_amini added a comment to D47073: Document and Enforce new Host Compiler Policy.
In D47073#1358663, @jfb wrote:

s/two/one/ : I've talked to Chandler already, and he was leaning on others (in large parts, me) to help Erich with the review

Jan 15 2019, 4:02 PM
mehdi_amini added a comment to D47073: Document and Enforce new Host Compiler Policy.
In D47073#1358640, @jfb wrote:
In D47073#1358593, @jfb wrote:

OK I think we've had more than enough bikeshed, over months, and in-person at the LLVM dev meeting. This is good enough, we want to warn people for the LLVM 8 branch which is tomorrow. Let's get this checked in today. We'll start a discussion on LLVM dev when anything *actually* changes, so nobody needs to panic just yet.

I strongly disagree with this right now: this is *not* OK to rush this as is.

If you need something in the release, then it can be done in a much less controversial way.

What makes you say this is being rushed?

Jan 15 2019, 1:41 PM
mehdi_amini added a comment to D47073: Document and Enforce new Host Compiler Policy.
In D47073#1358593, @jfb wrote:

OK I think we've had more than enough bikeshed, over months, and in-person at the LLVM dev meeting. This is good enough, we want to warn people for the LLVM 8 branch which is tomorrow. Let's get this checked in today. We'll start a discussion on LLVM dev when anything *actually* changes, so nobody needs to panic just yet.

Jan 15 2019, 1:32 PM
mehdi_amini added a comment to D47073: Document and Enforce new Host Compiler Policy.

Also the two levels (warnings vs errors) is not appropriate to accomplish what you're describing.

I don't understand what you're asking to change here

Jan 15 2019, 12:51 PM
mehdi_amini added a comment to D47073: Document and Enforce new Host Compiler Policy.

One release cycle with deprecating the version we're about to remove support for using a discardable cmake error seems like a good idea in general: we should encode this in the policy as well.

Jan 15 2019, 11:30 AM
mehdi_amini added a comment to D47073: Document and Enforce new Host Compiler Policy.
In D47073#1358067, @jfb wrote:
In D47073#1358039, @jfb wrote:

Yes: we want to warn folks early. This is just warning them, and they can opt-out.

The current version of the patch would issue a fatal error when using a host clang 3.5, not just a warning
(note that clang-3.4 is supposed to support C++14)

Yes it's a CMake error. The point is: you won't see it and will ignore it if it's just a CMake warning. What I meant was: we're giving everyone with older compilers a warning that they won't be supported soon. They can opt out and compile this once. Won't be true soon (because we'll move away from C++11). I want them to know ASAP.

Jan 15 2019, 11:28 AM
mehdi_amini added a comment to D47073: Document and Enforce new Host Compiler Policy.
In D47073#1358039, @jfb wrote:

Yes: we want to warn folks early. This is just warning them, and they can opt-out.

Jan 15 2019, 9:37 AM

Jan 14 2019

mehdi_amini updated subscribers of D56654: Update GettingStarted guide to recommend that people use the new official Git repository..
Jan 14 2019, 7:09 AM
mehdi_amini added inline comments to D56654: Update GettingStarted guide to recommend that people use the new official Git repository..
Jan 14 2019, 7:09 AM

Jan 11 2019

mehdi_amini added a comment to D47073: Document and Enforce new Host Compiler Policy.

I'd like to see docs/GettingStarted.rst updated to include some language from what Chandler mentioned. In particular upgrading a toolchain has to be *motivated* by explicit benefits, and the toolchains dropped must be evaluated with respect to the general availability for the users.

I think this is implied [...]

Jan 11 2019, 2:34 PM
mehdi_amini added inline comments to D47073: Document and Enforce new Host Compiler Policy.
Jan 11 2019, 1:01 PM
mehdi_amini requested changes to D47073: Document and Enforce new Host Compiler Policy.

I'd like to see docs/GettingStarted.rst updated to include some language from what Chandler mentioned. In particular upgrading a toolchain has to be *motivated* by explicit benefits, and the toolchains dropped must be evaluated with respect to the general availability for the users.

Jan 11 2019, 12:58 PM
mehdi_amini added inline comments to D47073: Document and Enforce new Host Compiler Policy.
Jan 11 2019, 10:03 AM

Jan 10 2019

mehdi_amini added a comment to D56567: [ADT] Force attribute used on functions marked as always_inline..

What about creating a new macrothat carry the semantic we're looking for here: "LLVM_KEEP_FOR_DEBUG"?
We can conditionally define it based on NDEBUG or add a CMake flag for it that is enabled in debug build (the latter has the advantage that it would allow to turn it on even in release builds when needing to debug these)

Jan 10 2019, 4:52 PM

Nov 26 2018

mehdi_amini added a comment to D54877: Update coding guidelines regarding use of `auto`.

at the end of the day, comments that arise in code review should take precedence over what the style guide does or doesn't say when it concerns readability, since it's an actual account of someone stating that they do or don't find something readable, and that's what we're trying to optimize for.

Nov 26 2018, 8:35 PM
mehdi_amini added inline comments to D54877: Update coding guidelines regarding use of `auto`.
Nov 26 2018, 11:59 AM
mehdi_amini updated subscribers of D35035: [InstCombine] Prevent memcpy generation for small data size.

That case (and a couple of similar tests that I tried) are handled by -sroa, so they probably never made it to instcombine in the 1st place. I don't know anything about SROA, but hopefully, it's making that transform using some principled logic. :)

Nov 26 2018, 9:50 AM

Nov 25 2018

mehdi_amini added a comment to D54887: WIP: hack to use DL for promoting to load/store.

(should fix PR39780 https://bugs.llvm.org/show_bug.cgi?id=39780 )

Nov 25 2018, 10:42 PM
mehdi_amini updated the summary of D54888: Optimize IRGen for load/stores of bitfields.
Nov 25 2018, 10:40 PM
mehdi_amini added a parent revision for D54888: Optimize IRGen for load/stores of bitfields: D54887: WIP: hack to use DL for promoting to load/store.
Nov 25 2018, 10:34 PM
mehdi_amini created D54888: Optimize IRGen for load/stores of bitfields.
Nov 25 2018, 10:34 PM
mehdi_amini added a child revision for D54887: WIP: hack to use DL for promoting to load/store: D54888: Optimize IRGen for load/stores of bitfields.
Nov 25 2018, 10:34 PM

Oct 22 2018

mehdi_amini added a comment to D53414: Add instructions for migrating branches from one git repository to another..

If we go with this document moving forward, I would first purge it so that it reflects the current situation. Otherwise we could also just archive it and start a new one with the actual action plan.
I feel adding more stuff here will be a bit confusing moving forward.

Oct 22 2018, 4:26 PM

Sep 13 2018

mehdi_amini added inline comments to D52023: [ThinLTO]Allow setting of maximum cache size with 64-bit number, and provide C-interface function for large values.
Sep 13 2018, 8:49 AM

Sep 10 2018

mehdi_amini added a comment to D51899: Remove extraneous ".a" suffix from baremetal clang_rt.builtins when compiling for baremetal..

@kristina both bfd and lld are adding the .a extension when you pass a lib through -l. Similarly to -llibfoo won't work, -lfoo.a will lead the linker to look for libfoo.a.a

Sep 10 2018, 5:23 PM
mehdi_amini edited reviewers for D51899: Remove extraneous ".a" suffix from baremetal clang_rt.builtins when compiling for baremetal., added: mehdi_amini; removed: joker-eph-DISABLED.
Sep 10 2018, 5:20 PM

Aug 20 2018

mehdi_amini added inline comments to D43690: [ThinLTO] Keep available_externally symbols live.
Aug 20 2018, 10:14 AM
mehdi_amini added inline comments to D43690: [ThinLTO] Keep available_externally symbols live.
Aug 20 2018, 10:12 AM

Aug 16 2018

mehdi_amini added inline comments to D43690: [ThinLTO] Keep available_externally symbols live.
Aug 16 2018, 9:21 PM
mehdi_amini accepted D50882: [ThinLTO] Correct documentation on default number of threads.

LGTM

Aug 16 2018, 9:14 PM

Aug 8 2018

mehdi_amini accepted D50476: [NFC] ConstantMerge: don't insert when find should be used.

LGTM

Aug 8 2018, 4:18 PM

Jul 31 2018

mehdi_amini added a comment to D49771: CodeGen: use non-zero memset when possible for automatic variables.

I'm worried, however, about generating a bunch more code than needed from clang in the hopes that the compiler will clean it up later.

Jul 31 2018, 5:10 PM
mehdi_amini added a comment to D49771: CodeGen: use non-zero memset when possible for automatic variables.
In D49771#1183380, @jfb wrote:

I'm curious: isn't the kind of optimization we should expect LLVM to provide?

Maybe? It seems obvious to do here since we know we'll probably want to be doing it, and I have another patch I'm working on which will make it that much more obviously useful to have here. The middle-end can definitely figure it out but it just seems like more work, later, so in the meantime we'd be looking at more stuff.

Jul 31 2018, 3:58 PM

Jul 30 2018

mehdi_amini added a comment to D49771: CodeGen: use non-zero memset when possible for automatic variables.

I'm curious: isn't the kind of optimization we should expect LLVM to provide?

Jul 30 2018, 1:55 PM

Jul 25 2018

mehdi_amini added a comment to D49777: [LTO] Don't internalize declarations.
but declarations cannot be internal.
Jul 25 2018, 2:00 PM

Jul 10 2018

mehdi_amini accepted D48783: [ThinLTO] Use std::map to get determistic imports files.

LGTM.

Jul 10 2018, 12:42 PM
mehdi_amini added a comment to D48783: [ThinLTO] Use std::map to get determistic imports files.

std::map is usually fairly slow, have you considered sorting at the time you write to the file instead? That would add a slow step when writing the files but wouldn't affect any in-memory operation.

Jul 10 2018, 10:50 AM

Feb 19 2018

mehdi_amini added a comment to D43253: bitcode support change for fast flags compatibility.

Thanks all for the great feedbacks!

The final solution is much better than a dumb bump of the bitcode version.

LGTM.

Note: we need buy-in from LLVM 6.0 release manager (@hans ?) that this will be cherry-picked there before landing this in trunk.

This seems fine for 6.0 (it needs to land soon though), but why does it need to be cherry-picked to the branch before landing on trunk?

Feb 19 2018, 11:37 AM

Feb 16 2018

mehdi_amini added a comment to D43253: bitcode support change for fast flags compatibility.

Thanks all for the great feedbacks!

The final solution is much better than a dumb bump of the bitcode version.

LGTM.

Feb 16 2018, 11:56 AM
mehdi_amini added a comment to D43253: bitcode support change for fast flags compatibility.

@hans : this needs to go in LLVM 6.0, is it OK?

Feb 16 2018, 8:21 AM
mehdi_amini added a reviewer for D43253: bitcode support change for fast flags compatibility: hans.
Feb 16 2018, 8:21 AM

Feb 15 2018

mehdi_amini updated subscribers of D43253: bitcode support change for fast flags compatibility.

Strongly disagree. The new test's purpose is to provide functional testing on the new flags in the new format. Sanjay, now would be a good time to chime in.

Feb 15 2018, 1:42 PM
mehdi_amini added a comment to D43253: bitcode support change for fast flags compatibility.

Case in point:

./bin/llvm-dis < /Users/michael_c_berg/llvm/llvm/test/Bitcode/compatibility-3.6.ll.bc | ./bin/FileCheck ../llvm/test/Bitcode/compatibility-3.6.ll
../llvm/test/Bitcode/compatibility-3.6.ll:617:11: error: expected string not found in input

; CHECK: %f.fast = fadd reassoc nnan ninf nsz arcp float %op1, %op2
         ^

<stdin>:445:2: note: scanning from here

%f.fast = fadd fast float %op1, %op2

in this case we are using my current patch with module version at 2 in the key .bc file, however we need the mapping as:

reassoc
nnan
ninf
nsz
arch
contract
afn

the new format writes reassoc in position 0 and aliases to UnsafeAlgebra incorrectly in this case, causing us to map fast, when less than fast was specified in the IR.
This will still be the case with the other format.

^
Feb 15 2018, 1:31 PM
mehdi_amini added a comment to D43253: bitcode support change for fast flags compatibility.

So the compatibility .bc files in check test have usages of the current flag layout with reassoc, afn and the new layout, as has been the case since last Nov. These tests are not old fast format but sub flags tests in the new format, and require the new mapping.

Feb 15 2018, 1:11 PM
mehdi_amini added a comment to D43348: Make FastMathFlags bitcode serialization to match LLVM 5.0 layout.

@tstellar YES.

Feb 15 2018, 1:00 PM
mehdi_amini added a comment to D43253: bitcode support change for fast flags compatibility.

For the 6 bitcode files, they are special context, as they require the current fast sub flags format for part of their use, so we have to bring them up into the current context as they require the use of the new flags selectively with the bumped version number.

Can you elaborate what you mean by "they require the current fast sub flags format for part of their use"?

Feb 15 2018, 1:00 PM
mehdi_amini added a comment to D43253: bitcode support change for fast flags compatibility.

I quickly put a patch to change the encoding, may be easier to discuss with code at hand: https://reviews.llvm.org/D43348
(I didn't try to build it, just a quick draft)

Feb 15 2018, 12:11 PM
mehdi_amini created D43348: Make FastMathFlags bitcode serialization to match LLVM 5.0 layout.
Feb 15 2018, 12:11 PM
mehdi_amini added inline comments to D43253: bitcode support change for fast flags compatibility.
Feb 15 2018, 11:19 AM
mehdi_amini added inline comments to D43253: bitcode support change for fast flags compatibility.
Feb 15 2018, 10:16 AM

Feb 14 2018

mehdi_amini added inline comments to D43253: bitcode support change for fast flags compatibility.
Feb 14 2018, 8:38 PM

Feb 13 2018

mehdi_amini added a comment to D43253: bitcode support change for fast flags compatibility.

Actually if we're making this change, we consider that bitcode generated between the introduction of the new fast-math flags and now isn't supported anymore.
If so then we could instead of bumping a version, change the encoding of the FMF record (or create a new record type), so that the old encoding is upgraded but not the new one.
That would seem to me to be more in line with the usual handling of such situation in the bitcode.

Feb 13 2018, 9:39 PM
mehdi_amini added inline comments to D43253: bitcode support change for fast flags compatibility.
Feb 13 2018, 9:36 PM
mehdi_amini added a comment to D43253: bitcode support change for fast flags compatibility.

For the 6 bitcode files, they are special context, as they require the current fast sub flags format for part of their use, so we have to bring them up into the current context as they require the use of the new flags selectively with the bumped version number.

Feb 13 2018, 9:16 PM
mehdi_amini added inline comments to D43253: bitcode support change for fast flags compatibility.
Feb 13 2018, 1:06 PM
mehdi_amini added a comment to D43253: bitcode support change for fast flags compatibility.

Uploaded above are the 6 bitcode files we will need to replace for check to run successfully as these files had the old version number in them.

Feb 13 2018, 1:02 PM

Feb 6 2018

mehdi_amini updated subscribers of D42267: [ThinLTO] Allow 0 to be a valid value for pruning interval for C LTO API..
Feb 6 2018, 1:04 PM

Jan 13 2018

mehdi_amini added a comment to D41297: [ThinLTO] Implement summary visualizer.

At which point of the API is this guarantee?

  1. ThinLTO.ModuleMap stores BitcodeModule objects and uses them during entire thin link phase (until backend threads are launched)
  2. BitcodeModule contains pointers to BC data, so this data should be actual for module to be parsed)
  3. Module summary is exported to .dot in CombinedIndexHook which is invoked in the beginning of thin link phase

None of these seems like API guarantee to me, it sounds like "this is what actually happens in practice today in this particular workflow".

It seems it must be a guarantee of the LTO API, since ThinLTO.ModuleMap holds the BitcodeModule objects and accesses their buffers through and after the thin link.

Jan 13 2018, 10:01 AM

Jan 12 2018

mehdi_amini added a comment to D41297: [ThinLTO] Implement summary visualizer.

At which point of the API is this guarantee?

  1. ThinLTO.ModuleMap stores BitcodeModule objects and uses them during entire thin link phase (until backend threads are launched)
  2. BitcodeModule contains pointers to BC data, so this data should be actual for module to be parsed)
  3. Module summary is exported to .dot in CombinedIndexHook which is invoked in the beginning of thin link phase
Jan 12 2018, 11:03 AM