Page MenuHomePhabricator

smeenai (Shoaib Meenai)
User

Projects

User does not belong to any projects.

User Details

User Since
Aug 19 2016, 10:21 AM (164 w, 5 d)

Recent Activity

Today

smeenai created D69076: [cmake] Pass external project source directories to sub-configures.
Wed, Oct 16, 5:58 PM · Restricted Project
smeenai committed rG6d1891c508fe: [AArch64] Fix offset calculation (authored by smeenai).
[AArch64] Fix offset calculation
Wed, Oct 16, 2:49 PM
smeenai closed D69018: [AArch64] Fix offset calculation.
Wed, Oct 16, 2:48 PM · Restricted Project
smeenai committed rL375043: [AArch64] Fix offset calculation.
[AArch64] Fix offset calculation
Wed, Oct 16, 2:47 PM
smeenai added a comment to D69018: [AArch64] Fix offset calculation.

Thanks for the quick review!

Wed, Oct 16, 1:38 PM · Restricted Project
smeenai updated the diff for D69018: [AArch64] Fix offset calculation.

Update test

Wed, Oct 16, 11:42 AM · Restricted Project
smeenai added a comment to D69018: [AArch64] Fix offset calculation.

@sdesmalen How does the new test case look?

Wed, Oct 16, 11:42 AM · Restricted Project
smeenai added inline comments to D69018: [AArch64] Fix offset calculation.
Wed, Oct 16, 10:55 AM · Restricted Project
smeenai updated the diff for D69018: [AArch64] Fix offset calculation.

Fix test

Wed, Oct 16, 10:55 AM · Restricted Project
smeenai added inline comments to D69018: [AArch64] Fix offset calculation.
Wed, Oct 16, 10:37 AM · Restricted Project
smeenai updated the diff for D69018: [AArch64] Fix offset calculation.

Use -run-pass=prologepilog in test

Wed, Oct 16, 10:37 AM · Restricted Project
smeenai added inline comments to D69018: [AArch64] Fix offset calculation.
Wed, Oct 16, 10:18 AM · Restricted Project
smeenai added a comment to D69018: [AArch64] Fix offset calculation.

Thanks for fixing this @smeenai!

I have no idea how to write a test for this; I'm completely unfamiliar with backends. I have a Swift compilation command that reproduces the OOM mentioned in the commit message, and I think I should be able to get IR or MIR from that, but I'd appreciate guidance crafting a test case if it's considered necessary for this commit.

You can create a MIR test with a single instruction accessing a pre-allocated stackslot with a very large offset, and check that the offset is generated correctly.

e.g. the following MIR

---
 name: D69018
 tracksRegLiveness: true
 fixedStack:
   - { id: 0, offset: 2147483648, size: 1}
 body: |
   bb.0:
     $x0 = LDRXui %fixed-stack.0, 0
     RET_ReallyLR
 ...

compiles with your patch, but fails to complete (i.e. it keeps running) without it.

Wed, Oct 16, 9:41 AM · Restricted Project
smeenai updated the diff for D69018: [AArch64] Fix offset calculation.

Add test

Wed, Oct 16, 9:41 AM · Restricted Project
smeenai added inline comments to D69018: [AArch64] Fix offset calculation.
Wed, Oct 16, 9:41 AM · Restricted Project

Yesterday

smeenai added inline comments to D69018: [AArch64] Fix offset calculation.
Tue, Oct 15, 10:36 PM · Restricted Project
smeenai added inline comments to D69018: [AArch64] Fix offset calculation.
Tue, Oct 15, 10:36 PM · Restricted Project
smeenai added a comment to D69018: [AArch64] Fix offset calculation.

I have no idea how to write a test for this; I'm completely unfamiliar with backends. I have a Swift compilation command that reproduces the OOM mentioned in the commit message, and I think I should be able to get IR or MIR from that, but I'd appreciate guidance crafting a test case if it's considered necessary for this commit.

Tue, Oct 15, 10:25 PM · Restricted Project
smeenai created D69018: [AArch64] Fix offset calculation.
Tue, Oct 15, 10:25 PM · Restricted Project

Mon, Oct 14

smeenai accepted D68966: [llvm-lipo] Add missing cast.

Is there any way to add a test for this?

Mon, Oct 14, 6:23 PM · Restricted Project
smeenai added a reviewer for D68964: cmake/modules/CheckAtomic.cmake: catch false positives in RISC-V: jyknight.

libc++ also has a version of this check (https://github.com/llvm/llvm-project/blob/master/libcxx/cmake/Modules/CheckLibcxxAtomic.cmake). Does that need to be adjusted as well?

Mon, Oct 14, 5:46 PM · Restricted Project

Thu, Oct 10

smeenai accepted D68833: [CMake] Re-order runtimes in the order of dependencies.

Makes sense to me, particularly since this is generalizing what we're already doing for compiler-rt.

Thu, Oct 10, 8:02 PM · Restricted Project

Tue, Oct 8

smeenai accepted D68648: [CMake] Only detect the linker once in AddLLVM.cmake.

This only works because of a specific detail of LLVM's build system. The variable will get set in the directory scope, so different directories including this module will still duplicate the check. Here's a simple test I did, using cmake version 3.12.1 (run this as a script):

Tue, Oct 8, 6:28 PM · Restricted Project

Mon, Oct 7

smeenai accepted D68412: [clang] [cmake] Support LLVM_DISTRIBUTION_COMPONENTS in stand-alone build.

LGTM

Mon, Oct 7, 10:25 AM · Restricted Project

Wed, Oct 2

smeenai added a comment to D68357: [libc++abi] Do not export some implementation-detail functions.

Do we not build libc++abi with -fvisibility=hidden? That would also have prevented this, right?

Wed, Oct 2, 2:42 PM · Restricted Project, Restricted Project

Fri, Sep 20

smeenai accepted D67758: [llvm-lipo] Add support for archives.

LGTM

Fri, Sep 20, 3:52 PM · Restricted Project

Thu, Sep 19

smeenai committed rL372346: [Analysis] Allow -scalar-evolution-max-iterations more than once.
[Analysis] Allow -scalar-evolution-max-iterations more than once
Thu, Sep 19, 11:29 AM
smeenai committed rGd89f2d872df3: [Analysis] Allow -scalar-evolution-max-iterations more than once (authored by smeenai).
[Analysis] Allow -scalar-evolution-max-iterations more than once
Thu, Sep 19, 11:26 AM
smeenai closed D67512: [Analysis] Allow -scalar-evolution-max-iterations more than once.
Thu, Sep 19, 11:25 AM · Restricted Project
smeenai added a comment to D67512: [Analysis] Allow -scalar-evolution-max-iterations more than once.

This patch individually is fine, but why are you setting scalar-evolution-max-iterations in the first place? It is a debug option that end-users should ideally never have to change.

Thu, Sep 19, 10:39 AM · Restricted Project

Wed, Sep 18

smeenai updated subscribers of D67700: [Object] Extend MachOUniversalBinary::getObjectForArch.
Wed, Sep 18, 10:49 AM · Restricted Project

Tue, Sep 17

smeenai updated the diff for D67512: [Analysis] Allow -scalar-evolution-max-iterations more than once.

Add test

Tue, Sep 17, 3:27 PM · Restricted Project
smeenai added a comment to D67512: [Analysis] Allow -scalar-evolution-max-iterations more than once.

Added test, as suggested by @jdoerfert on IRC.

Tue, Sep 17, 3:27 PM · Restricted Project
smeenai commandeered D67512: [Analysis] Allow -scalar-evolution-max-iterations more than once.
Tue, Sep 17, 10:43 AM · Restricted Project

Sep 6 2019

smeenai committed rL371272: Request commit access for smeenai.
Request commit access for smeenai
Sep 6 2019, 4:51 PM

Aug 7 2019

smeenai added a comment to D65924: Revert "[cmake] Pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to NATIVE configure".
In D65924#1620382, @jfb wrote:

I take it LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN will be going away entirely? If so, LGTM.

I intend to leave it there so it's easy to do the same dance for the next compiler bump. It won't be active for a bit, but we also won't have to re-agree on how to bump the version next time around :)

Aug 7 2019, 10:41 PM · Restricted Project
smeenai accepted D65924: Revert "[cmake] Pass LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN to NATIVE configure".

I take it LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN will be going away entirely? If so, LGTM.

Aug 7 2019, 10:34 PM · Restricted Project
smeenai added a comment to D65831: libc++: add `-include` or `/FI` to the interface compile definitions.

Hmm, yes, it is for use from the build tree. I don't see how INTERFACE_INCLUDE_DIRECTORIES can do a -include though. It has to be INTERFACE_COMPILE_OPTIONS or INTERFACE_COMPILE_DEFINITIONS.

Aug 7 2019, 1:30 PM

Aug 6 2019

smeenai requested changes to D65831: libc++: add `-include` or `/FI` to the interface compile definitions.

When libc++ is installed, the __config_site and __config are concatenated to make a single __config. I'm imagining this is specific to using libc++ from the build tree? If so, you should use INTERFACE_INCLUDE_DIRECTORIES and $<BUILD_INTERFACE:...> to limit it to builds.

Aug 6 2019, 7:29 PM
smeenai added a parent revision for D65841: [Driver] Switch -stdlib++-isystem test to -###-verbatim: D65839: [Driver] Add verbatim dry run option.
Aug 6 2019, 6:21 PM · Restricted Project
smeenai added a child revision for D65839: [Driver] Add verbatim dry run option: D65841: [Driver] Switch -stdlib++-isystem test to -###-verbatim.
Aug 6 2019, 6:21 PM · Restricted Project
smeenai created D65841: [Driver] Switch -stdlib++-isystem test to -###-verbatim.
Aug 6 2019, 6:20 PM · Restricted Project
smeenai updated the diff for D65839: [Driver] Add verbatim dry run option.

Output to stdout

Aug 6 2019, 6:18 PM · Restricted Project
smeenai added a comment to D65839: [Driver] Add verbatim dry run option.

I'm not tied to the name -###-verbatim and am open to suggestions if anyone can think of something better.

Aug 6 2019, 6:04 PM · Restricted Project
smeenai abandoned D64538: [Driver] Don't escape backslashes on Windows.

Abandoning in favor of D65839

Aug 6 2019, 6:02 PM · Restricted Project
smeenai added a parent revision for D65839: [Driver] Add verbatim dry run option: D65838: [Driver] Use enumeration for quoting mode. NFC.
Aug 6 2019, 6:02 PM · Restricted Project
smeenai added a child revision for D65838: [Driver] Use enumeration for quoting mode. NFC: D65839: [Driver] Add verbatim dry run option.
Aug 6 2019, 6:02 PM · Restricted Project
smeenai created D65839: [Driver] Add verbatim dry run option.
Aug 6 2019, 6:02 PM · Restricted Project
smeenai created D65838: [Driver] Use enumeration for quoting mode. NFC.
Aug 6 2019, 5:45 PM · Restricted Project
smeenai accepted D65818: Add order-dependencies to object libraries.

LGTM

Aug 6 2019, 10:58 AM · Restricted Project
smeenai committed rGfe08528c8e8a: [DirectoryWatcher] Fix asserts Mac builds (authored by smeenai).
[DirectoryWatcher] Fix asserts Mac builds
Aug 6 2019, 12:16 AM
smeenai committed rL367984: [DirectoryWatcher] Fix asserts Mac builds.
[DirectoryWatcher] Fix asserts Mac builds
Aug 6 2019, 12:14 AM

Aug 5 2019

smeenai committed rGb50e8c592789: [Driver] Introduce -stdlib++-isystem (authored by smeenai).
[Driver] Introduce -stdlib++-isystem
Aug 5 2019, 11:50 PM
smeenai committed rL367982: [Driver] Introduce -stdlib++-isystem.
[Driver] Introduce -stdlib++-isystem
Aug 5 2019, 11:49 PM
smeenai closed D64089: [Driver] Introduce -stdlib++-isystem.
Aug 5 2019, 11:49 PM · Restricted Project, Restricted Project
smeenai added a reviewer for D64089: [Driver] Introduce -stdlib++-isystem: rnk.

Adding @rnk as someone familiar with the driver/frontend :)

Aug 5 2019, 7:38 PM · Restricted Project, Restricted Project

Jul 30 2019

smeenai accepted D65477: [build] add the ability to create a symlink for lipo.

LGTM

Jul 30 2019, 2:08 PM · Restricted Project

Jul 26 2019

smeenai accepted D65342: add 'a' to chmod in llvm-lipo executability tests.

LGTM, thanks!

Jul 26 2019, 11:41 AM · Restricted Project

Jul 24 2019

smeenai committed rG5aee1c6b102f: [llvm-lipo] Implement alignment function in -create (authored by smeenai).
[llvm-lipo] Implement alignment function in -create
Jul 24 2019, 5:31 PM
smeenai committed rGa67f6f17467f: [Object] Add public MaxSectionAlignment to MachOUniversal (authored by smeenai).
[Object] Add public MaxSectionAlignment to MachOUniversal
Jul 24 2019, 5:30 PM
smeenai committed rG7418b10b1652: [llvm-lipo] Add test for -verify_archs (authored by smeenai).
[llvm-lipo] Add test for -verify_archs
Jul 24 2019, 5:30 PM
smeenai committed rL366970: [llvm-lipo] Implement alignment function in -create.
[llvm-lipo] Implement alignment function in -create
Jul 24 2019, 5:30 PM
smeenai closed D64871: [llvm-lipo] Implement alignment function in -create.
Jul 24 2019, 5:30 PM · Restricted Project
smeenai committed rL366969: [Object] Add public MaxSectionAlignment to MachOUniversal.
[Object] Add public MaxSectionAlignment to MachOUniversal
Jul 24 2019, 5:30 PM
smeenai closed D65117: [llvm-Object] Added public MaxSectionAlignment to MachOUniversal.
Jul 24 2019, 5:29 PM · Restricted Project
smeenai committed rL366968: [llvm-lipo] Add test for -verify_archs.
[llvm-lipo] Add test for -verify_archs
Jul 24 2019, 5:29 PM
smeenai closed D65251: [llvm-lipo] Add test for -verify_archs.
Jul 24 2019, 5:29 PM · Restricted Project
smeenai added inline comments to D64089: [Driver] Introduce -stdlib++-isystem.
Jul 24 2019, 5:19 PM · Restricted Project, Restricted Project
smeenai accepted D65251: [llvm-lipo] Add test for -verify_archs.

LGTM

Jul 24 2019, 5:12 PM · Restricted Project

Jul 23 2019

smeenai updated subscribers of rL366765: [Statepoints] Fix a bug in statepoint lowering for functions w/no-realign-stack.
Jul 23 2019, 9:56 AM
smeenai added a reviewer for D65149: [Format] Add test demonstrating PR42722: MyDeveloperDay.
Jul 23 2019, 8:16 AM · Restricted Project

Jul 22 2019

smeenai added inline comments to rL366765: [Statepoints] Fix a bug in statepoint lowering for functions w/no-realign-stack.
Jul 22 2019, 10:32 PM
smeenai added inline comments to rL366765: [Statepoints] Fix a bug in statepoint lowering for functions w/no-realign-stack.
Jul 22 2019, 10:32 PM
smeenai committed rG99ccc3c9f144: [llvm-lipo] Implement -info (authored by smeenai).
[llvm-lipo] Implement -info
Jul 22 2019, 5:46 PM
smeenai committed rL366772: [llvm-lipo] Implement -info.
[llvm-lipo] Implement -info
Jul 22 2019, 5:42 PM
smeenai closed D64668: [llvm-lipo] Implement -info.
Jul 22 2019, 5:41 PM · Restricted Project

Jul 19 2019

smeenai added a comment to D61479: Finish "Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO".

eh, the summary here doesn't get updated from the actual git commit message :(

thanks for the reviews!

Jul 19 2019, 2:38 PM · Restricted Project, Restricted Project, Restricted Project
smeenai committed rGb50f10875b3d: [llvm-lipo] Remove trailing whitespace. NFC (authored by smeenai).
[llvm-lipo] Remove trailing whitespace. NFC
Jul 19 2019, 10:24 AM
smeenai committed rL366595: [llvm-lipo] Remove trailing whitespace. NFC.
[llvm-lipo] Remove trailing whitespace. NFC
Jul 19 2019, 10:20 AM

Jul 18 2019

smeenai committed rG16a9632558e7: Reapply [llvm-lipo] Implement -create (with hardcoded alignments) (authored by smeenai).
Reapply [llvm-lipo] Implement -create (with hardcoded alignments)
Jul 18 2019, 3:49 PM
smeenai committed rL366512: Reapply [llvm-lipo] Implement -create (with hardcoded alignments).
Reapply [llvm-lipo] Implement -create (with hardcoded alignments)
Jul 18 2019, 3:48 PM
smeenai accepted D64837: [cmake] Convert the NATIVE llvm build process to be project agnostic.

LGTM

Jul 18 2019, 3:20 PM · Restricted Project
smeenai accepted D64873: Remove the static initialize introduced in r365099.

Sorry, I missed this. Thanks, LGTM.

Jul 18 2019, 1:22 PM · Restricted Project

Jul 17 2019

smeenai accepted D64846: [cmake] Add NATIVE build for cross compiling standalone builds.

LGTM

Jul 17 2019, 4:42 PM
smeenai added a comment to D64846: [cmake] Add NATIVE build for cross compiling standalone builds.

You can use CROSS_TOOLCHAIN_FLAGS_<PROJECT_NAME> (in this case CROSS_TOOLCHAIN_FLAGS_LLDB) to pass additional variables to the cross-compiling configure. That seems more appropriate for setting these options instead of hardcoding them in LLDB's CMake.

I think LLDB_PATH_TO_NATIVE_CLANG_BUILD along with the error that would occur makes it much clearer to the user what's happening. CROSS_TOOLCHAIN_FLAGS is a hell of a lot more ambiguous as to it's purpose than the former. If you've never heard of the NATIVE build then this would point it out to you relatively easily.

Jul 17 2019, 3:40 PM
smeenai added a comment to D64837: [cmake] Convert the NATIVE llvm build process to be project agnostic.

This just seems like it's replacing all instances of LLVM with ${CMAKE_PROJECT_NAME}?

I think it'd be cleaner and more explicit to pass an additional project name parameter to llvm_create_cross_target instead of implicitly using ${CMAKE_PROJECT_NAME}. There's some prior art for that, e.g. in https://reviews.llvm.org/diffusion/L/browse/llvm/trunk/cmake/modules/AddLLVM.cmake;366290$1009?as=source&blame=off

That's what I did originally. However, the users of build_natve_tool wouldn't have the proper context to know what to use. It's only non-llvm specific usage is within add_tablegen which would then have to learn how to decide what project_name variable to pass in. e.g. if lldb is part of ENABLE_PROJECTS then add_tablegen should call llvm_native_build(LLVM NATIVE ...) else llvm_native_build(LLDB NATIVE ...). So we'd have to propagate that to all users of add_tablegen where we'd have to figure out whether the build is standalone or not via checking CMAKE_PROJECT_NAME anyways. e.g.

 if (${CMAKE_PROJECT_NAME} MATCHES lldb)
    add_tablegen(lldb lldb lldb-tblgen)
else()
    add_tablegen(llvm lldb lldb-tblgen)
endif()

I'm not convinced that adding the granularity to choose your llvm_create_cross_target project is worth propagating the configuration outwards given that there are no users that don't satisfy CMAKE_PROJECT_NAME == project_name.

An alternative would be to have some global variable llvm_cross_targets list that build_native_tool iterates over. But this is making an already clumsy solution more clumsy.

Jul 17 2019, 3:39 PM · Restricted Project

Jul 16 2019

smeenai added a comment to D64846: [cmake] Add NATIVE build for cross compiling standalone builds.

Having Swift-specific options in here is a non-starter, since Swift support isn't in mainline LLDB yet.

You can use CROSS_TOOLCHAIN_FLAGS_<PROJECT_NAME> (in this case CROSS_TOOLCHAIN_FLAGS_LLDB) to pass additional variables to the cross-compiling configure. That seems more appropriate for setting these options instead of hardcoding them in LLDB's CMake.

Jul 16 2019, 10:28 PM
smeenai added inline comments to D64837: [cmake] Convert the NATIVE llvm build process to be project agnostic.
Jul 16 2019, 10:26 PM · Restricted Project
smeenai added a comment to D64837: [cmake] Convert the NATIVE llvm build process to be project agnostic.

This just seems like it's replacing all instances of LLVM with ${CMAKE_PROJECT_NAME}?

Jul 16 2019, 10:25 PM · Restricted Project
smeenai requested changes to D64846: [cmake] Add NATIVE build for cross compiling standalone builds.

Having Swift-specific options in here is a non-starter, since Swift support isn't in mainline LLDB yet.

Jul 16 2019, 10:21 PM
smeenai added inline comments to D64837: [cmake] Convert the NATIVE llvm build process to be project agnostic.
Jul 16 2019, 4:04 PM · Restricted Project
smeenai added a comment to D63735: [MachOObjectFile]Added Valid Architecture Function.

This adds an unnecessary static initializer to the MachOObject.cpp. Can you move the array of validArchs into filescope? You can declare it in getValidArchs() and use getValidArchs() in isValidArchs.

Jul 16 2019, 11:24 AM · Restricted Project

Jul 15 2019

smeenai added a comment to D64089: [Driver] Introduce -stdlib++-isystem.

Ping.

Jul 15 2019, 7:27 PM · Restricted Project, Restricted Project
smeenai committed rGc9e3c8301446: Revert [llvm-lipo] Implement -create (with hardcoded alignments) (authored by smeenai).
Revert [llvm-lipo] Implement -create (with hardcoded alignments)
Jul 15 2019, 3:45 PM
smeenai committed rL366144: Revert [llvm-lipo] Implement -create (with hardcoded alignments).
Revert [llvm-lipo] Implement -create (with hardcoded alignments)
Jul 15 2019, 3:45 PM
smeenai committed rG67cee1dc7ee2: [llvm-lipo] Implement -create (with hardcoded alignments) (authored by smeenai).
[llvm-lipo] Implement -create (with hardcoded alignments)
Jul 15 2019, 3:30 PM
smeenai committed rL366142: [llvm-lipo] Implement -create (with hardcoded alignments).
[llvm-lipo] Implement -create (with hardcoded alignments)
Jul 15 2019, 3:30 PM
smeenai closed D64102: [llvm-lipo] Implement -create part 1.
Jul 15 2019, 3:30 PM · Restricted Project
smeenai added a comment to D64461: [lld-link] implement -thinlto-index-only.

Distributed ThinLTO doesn't support archives: http://lists.llvm.org/pipermail/llvm-dev/2019-June/133145.html. @tejohnson suggested -start-lib -end-lib as a workaround, but that's not a thing for COFF. Do you have plans for archive support, or is that not something you need to deal with for your use cases?

Jul 15 2019, 3:01 PM · Restricted Project
smeenai added inline comments to D64668: [llvm-lipo] Implement -info.
Jul 15 2019, 11:47 AM · Restricted Project