weimingz (Weiming Zhao)
User

Projects

User does not belong to any projects.

User Details

User Since
Nov 19 2012, 2:50 AM (291 w, 6 d)

Recent Activity

Apr 20 2018

weimingz added inline comments to D45893: add more "anchors".
Apr 20 2018, 11:06 PM
weimingz updated the diff for D45893: add more "anchors".

maybe we can apply the -Wweak-vtable flag lib by lib. does the CMakeList support it?

Apr 20 2018, 11:03 PM
weimingz created D45893: add more "anchors".
Apr 20 2018, 11:21 AM

Apr 15 2018

weimingz committed rL330107: Rename ObjectMemoryBuffer to SmallVectorMemoryBuffer; NFCI.
Rename ObjectMemoryBuffer to SmallVectorMemoryBuffer; NFCI
Apr 15 2018, 8:47 PM
weimingz closed D45661: Rename ObjectMemoryBuffer to SmallVectorMemoryBuffer; NFCI.
Apr 15 2018, 8:47 PM

Apr 14 2018

weimingz created D45661: Rename ObjectMemoryBuffer to SmallVectorMemoryBuffer; NFCI.
Apr 14 2018, 10:36 PM
weimingz added a comment to D45244: Add missing vtable anchors.

Great - thanks for sticking with it, sorry for my dodgy explanations!

If you're adding in anchors, are you using -Wweak-vtables to find them? If you're pushing through to make LLVM (& hopefully Clang/other LLVM subprojects) -Wweak-vtables clean, perhaps you can turn on the warning in the CMake config once it's clean so we don't regress this again? (it'd also be interesting to do some kind of analysis to see whether avoiding weak vtables is /actually/ worthwhile - like maybe making a temporary/local/non-committed change to change all the explicit anchors into inline functions (unanchoring them) & see if builds are much larger or longer, etc)

Apr 14 2018, 10:33 PM
weimingz committed rL330093: NFC: Move ObjectMemoryBuffer to support.
NFC: Move ObjectMemoryBuffer to support
Apr 14 2018, 10:20 PM
weimingz closed D45606: NFC: Move ObjectMemoryBuffer to support.
Apr 14 2018, 10:20 PM

Apr 13 2018

weimingz updated the diff for D17741: adds __FILE_BASENAME__ builtin macro.

split the original into two parts. This one supports -ffile-macro-prefix-to-remove function.

Apr 13 2018, 6:05 PM
JetForMe awarded D17741: adds __FILE_BASENAME__ builtin macro a Like token.
Apr 13 2018, 1:13 PM
weimingz added a comment to D45606: NFC: Move ObjectMemoryBuffer to support.

Sure. How about do it in a separate patch?

Apr 13 2018, 11:12 AM

Apr 12 2018

weimingz created D45606: NFC: Move ObjectMemoryBuffer to support.
Apr 12 2018, 7:07 PM

Apr 11 2018

weimingz committed rL329861: Add missing vtable anchors.
Add missing vtable anchors
Apr 11 2018, 4:13 PM
weimingz closed D45244: Add missing vtable anchors.
Apr 11 2018, 4:13 PM
weimingz updated the diff for D45244: Add missing vtable anchors.

@dblaikie you're right. I modified CMakeLists.txt rather than LLVMBuild.txt

Apr 11 2018, 3:25 PM
weimingz added a comment to D45244: Add missing vtable anchors.

That sort of surprises me - if that were the case, there would be no point
having LLVMBuild.txt files in any libraries, I would think?

Apr 11 2018, 1:41 PM
weimingz added a comment to D45244: Add missing vtable anchors.

I meant what happens if you remove the changes to tools/lto/LLVMBuild.txt
and tools/llvm-lto/LLVMBuild.txt and /only/ have a change to
lib/LTO/LLVMBuild.txt - is that sufficient to make the build work?

Apr 11 2018, 10:58 AM
weimingz added a comment to D45244: Add missing vtable anchors.

I put a dependency on tools/llvm-lto as well. From my build (default CMake config), it works.

Apr 11 2018, 10:17 AM

Apr 10 2018

weimingz updated the diff for D45244: Add missing vtable anchors.

add dependency upon MCJIT for LTO due to the use of ObjectMemoryBuffer

Apr 10 2018, 3:45 PM

Apr 9 2018

weimingz added a comment to D45244: Add missing vtable anchors.

If I choose to define ObjectMemoryBuffer::anchor() in MCJIT.cpp (the module that uses ObjectMemoryBuffer), then I got error like:
../../lib/libLLVMLTO.a(ThinLTOCodeGenerator.cpp.o): In function `ObjectMemoryBuffer':
llvm/ExecutionEngine/ObjectMemoryBuffer.h:41: undefined reference to `vtable for llvm::ObjectMemoryBuffer'

Apr 9 2018, 4:59 PM

Apr 5 2018

weimingz added a reviewer for D45244: Add missing vtable anchors: eli.friedman.
Apr 5 2018, 7:29 PM
weimingz added a comment to D41316: [libcxx] Allow random_device to be built optionally.

Thanks Eli!

Apr 5 2018, 7:28 PM

Apr 4 2018

weimingz added a reviewer for D45244: Add missing vtable anchors: jlebar.
Apr 4 2018, 12:45 AM
weimingz added a comment to D45244: Add missing vtable anchors.

When I statically linking a project (built with RTTI) against LLVM OrcJIT (default built with no-RTTI), I got a couple of "undefined reference to type info" error.

Apr 4 2018, 12:43 AM
weimingz created D45244: Add missing vtable anchors.
Apr 4 2018, 12:36 AM

Mar 7 2018

weimingz committed rL326969: [AArch64] Fix UB about shift amount exceeds data bit-width.
[AArch64] Fix UB about shift amount exceeds data bit-width
Mar 7 2018, 4:30 PM
weimingz closed D44234: [AArch64] Fix UB about shift amount exceeds data bit-width.
Mar 7 2018, 4:30 PM
weimingz created D44234: [AArch64] Fix UB about shift amount exceeds data bit-width.
Mar 7 2018, 3:51 PM

Mar 5 2018

weimingz added a comment to D41316: [libcxx] Allow random_device to be built optionally.

gentle ping?

Mar 5 2018, 10:43 AM

Feb 23 2018

weimingz added a comment to D41316: [libcxx] Allow random_device to be built optionally.

ping?

Feb 23 2018, 11:48 AM

Feb 12 2018

weimingz updated the diff for D41316: [libcxx] Allow random_device to be built optionally.

Modified the random generator in filesystem_test_helper to use high_resolution_clock as seed.

Feb 12 2018, 6:55 PM

Feb 9 2018

weimingz added a comment to D41316: [libcxx] Allow random_device to be built optionally.

ping?

Feb 9 2018, 10:07 AM

Jan 30 2018

weimingz updated the diff for D41316: [libcxx] Allow random_device to be built optionally.

Disable tests that depend on random_device.
filesystem tests rely on random_device as seed to create random path. Although it's possible to avoid the random_device but if the build target has no random_device, it's very possible that neither filesystem nor other seeding device like clock is available.

Jan 30 2018, 6:15 PM

Jan 24 2018

weimingz committed rL323354: [ARM] Expand long shifts for Thumb1 to __aeabi_ calls.
[ARM] Expand long shifts for Thumb1 to __aeabi_ calls
Jan 24 2018, 10:02 AM
weimingz closed D42401: [ARM] Expand long shifts for Thumb1 to __aeabi_ calls.
Jan 24 2018, 10:02 AM

Jan 23 2018

weimingz updated the diff for D42401: [ARM] Expand long shifts for Thumb1 to __aeabi_ calls.

As Sam suggests, add more checks in lit tests to make sure only "bl" is used.

Jan 23 2018, 9:39 AM

Jan 22 2018

weimingz added a comment to D42401: [ARM] Expand long shifts for Thumb1 to __aeabi_ calls.

On Thumb1, i64 shift is lowered to 20 instructions. For example:
For code like
unsigned long long foo(unsigned long long x, unsigned y) { return x << y;}

Jan 22 2018, 5:16 PM
weimingz created D42401: [ARM] Expand long shifts for Thumb1 to __aeabi_ calls.
Jan 22 2018, 5:11 PM

Jan 11 2018

weimingz added a comment to D41316: [libcxx] Allow random_device to be built optionally.

any suggestions?

Jan 11 2018, 10:20 AM

Jan 5 2018

weimingz added a comment to D41316: [libcxx] Allow random_device to be built optionally.

We can wrap the random_device as a minstd_rand, a linear congruential enginer that a lot of C lib uses for rand().
However based on documentation, we should just provides dummy implementation which throws an exception in the constructor of random_device [1,2]
But compared with run-time exception, a link time error is better if we simply skip the implementation. Any thoughts?

Jan 5 2018, 2:59 PM

Jan 2 2018

weimingz added a comment to D41316: [libcxx] Allow random_device to be built optionally.

Should we go with current patch? or provide a srand/rand based implementation as an option?

Jan 2 2018, 10:55 AM

Dec 16 2017

weimingz added a comment to D41316: [libcxx] Allow random_device to be built optionally.

Does it make sense to provide an implementation based on C99 rand?
like
#ifdef _LIBCPP_USING_C99_RANDOM

srand(0), rand()
Dec 16 2017, 10:58 AM

Dec 15 2017

weimingz created D41316: [libcxx] Allow random_device to be built optionally.
Dec 15 2017, 4:56 PM

Nov 30 2017

weimingz added a comment to D40245: IR printing improvement for function passes - introducing -print-module-scope.

ping?

Nov 30 2017, 11:03 AM

Nov 28 2017

weimingz committed rL319257: [compiler-rt] Avoid unnecessarily hiding inline visibility [NFC].
[compiler-rt] Avoid unnecessarily hiding inline visibility [NFC]
Nov 28 2017, 3:42 PM
weimingz closed D40269: [compiler-rt] Avoid unnecessarily hiding inline visibility [NFC] by committing rL319257: [compiler-rt] Avoid unnecessarily hiding inline visibility [NFC].
Nov 28 2017, 3:42 PM

Nov 20 2017

weimingz added a comment to D40269: [compiler-rt] Avoid unnecessarily hiding inline visibility [NFC].

Hold on. Why do we need this flag? There is no c++ code in builtins.

Nov 20 2017, 3:31 PM
weimingz added a comment to D40269: [compiler-rt] Avoid unnecessarily hiding inline visibility [NFC].

Hold on. Why do we need this flag? There is no c++ code in builtins.

Nov 20 2017, 3:30 PM
weimingz added reviewers for D40269: [compiler-rt] Avoid unnecessarily hiding inline visibility [NFC]: compnerd, peter.smith.

LGTM. Adding Saleem and Peter for confirming.

Nov 20 2017, 3:25 PM

Nov 9 2017

weimingz committed rL317814: [Builtins] Do not use tailcall for Thumb1.
[Builtins] Do not use tailcall for Thumb1
Nov 9 2017, 9:33 AM
weimingz closed D39700: [Builtins] Do not use tailcall for Thumb1 by committing rL317814: [Builtins] Do not use tailcall for Thumb1.
Nov 9 2017, 9:33 AM

Nov 7 2017

weimingz added a comment to D39700: [Builtins] Do not use tailcall for Thumb1.

If compiler-rt is to provide optimized version, then, should MUSL just forwards the calls like memcpy ->__aeabi_memcpy ? Because libc is usually appear first in linking order, a standard implementation in libc will hide the optimized version in compiler-rt.

Nov 7 2017, 2:25 PM
weimingz added a comment to D39700: [Builtins] Do not use tailcall for Thumb1.

I agree that we must avoid the 16-bit branch on Thumb1 and that the code sequence is fine for that purpose.

I do wonder if compiler-rt should define the aeabi_... forwarding functions in it? I would have expected the C-library to define them. For example the v6-m libgcc.a does not define the aeabi memcpy family, the forwarding is done in newlib. Similarly Arm's proprietary compiler's C library defines aeabi_memcpy that just falls through directly into memcpy. I'm guessing that there is some C-library that we support that does not define the aeabi_ function?

Nov 7 2017, 9:46 AM

Nov 6 2017

weimingz updated the diff for D39700: [Builtins] Do not use tailcall for Thumb1.

add memcpy

Nov 6 2017, 2:36 PM
weimingz created D39700: [Builtins] Do not use tailcall for Thumb1.
Nov 6 2017, 2:27 PM
weimingz added a comment to D39600: [docs][ARM] Add HowTo for cross compiling and testing compiler-rt builtins on Arm.

Should we use "ARM" instead of "Arm" ?

Nov 6 2017, 12:17 PM

Sep 26 2017

weimingz added a comment to D38268: [Builtins] ARM: Fix msr assembly instruction use for Thumb2..

LGTM. (Let Saleem to sign off)

Sep 26 2017, 4:02 PM
weimingz added a comment to D38227: [Builtins] ARM: Fix assembling files in thumb mode..

LGTM.

Sep 26 2017, 3:54 PM

Sep 19 2017

weimingz committed rL313694: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions.
[libc++] Replace __sync_* functions with __libcpp_atomic_* functions
Sep 19 2017, 4:19 PM
weimingz closed D35235: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions by committing rL313694: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions.
Sep 19 2017, 4:19 PM
weimingz updated the diff for D35235: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions.

minor change

Sep 19 2017, 4:09 PM
weimingz updated the diff for D35235: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions.

Moved the inclusion from stdexcept.cpp into refstring.h

Sep 19 2017, 1:36 PM

Sep 6 2017

weimingz added a reviewer for D31139: [LLVMbugs] [Bug 18710] Only generate .ARM.exidx and .ARM.extab when needed with EHABI: eli.friedman.
Sep 6 2017, 9:24 AM

Aug 30 2017

weimingz added a reviewer for D35235: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions: eli.friedman.
Aug 30 2017, 9:28 AM

Aug 22 2017

weimingz added inline comments to D36555: Move x86-specific sources to x86-specific source lists..
Aug 22 2017, 3:59 PM
weimingz added reviewers for D36555: Move x86-specific sources to x86-specific source lists.: rengolin, compnerd.

LGTM. Adding Renato and Saleem to approve.

Aug 22 2017, 3:59 PM

Aug 15 2017

weimingz updated the diff for D36762: [Builtins][ARM] Force ARM state for bswap for pre-ARMv6.

guard the "DEFINE_CODE_STATE" with "__ARM_ARCH < 6" check.

Aug 15 2017, 12:57 PM
weimingz created D36762: [Builtins][ARM] Force ARM state for bswap for pre-ARMv6.
Aug 15 2017, 11:45 AM

Aug 14 2017

weimingz committed rL310890: [builtins] fix build error on non-ARM for r310884.
[builtins] fix build error on non-ARM for r310884
Aug 14 2017, 2:45 PM
weimingz added a comment to D35235: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions.

ping @EricWF

Aug 14 2017, 1:59 PM
weimingz committed rL310884: [builtins][ARM] Select correct code fragments when compiling for….
[builtins][ARM] Select correct code fragments when compiling for…
Aug 14 2017, 1:49 PM
weimingz closed D31220: [builtins][ARM] Select correct code fragments when compiling for Thumb1/Thum2/ARM ISA by committing rL310884: [builtins][ARM] Select correct code fragments when compiling for….
Aug 14 2017, 1:49 PM
weimingz updated the diff for D31220: [builtins][ARM] Select correct code fragments when compiling for Thumb1/Thum2/ARM ISA.

remove unreleated change (CMakefile) and address comments from Saleem

Aug 14 2017, 1:48 PM
weimingz added a comment to D35970: Teach cc1as driver to accept ARM ropi/rwpi reloc model.

I think it would be better to reject these options than to silently accept them, unless you plan on using them to emit build attributes.

Aug 14 2017, 1:29 PM

Aug 11 2017

weimingz added a comment to D35970: Teach cc1as driver to accept ARM ropi/rwpi reloc model.

ping?

Aug 11 2017, 10:42 AM

Aug 7 2017

weimingz added a comment to D35970: Teach cc1as driver to accept ARM ropi/rwpi reloc model.

And since it's an assertion, in Release build, the flag will still be accepted silently.

Aug 7 2017, 5:53 PM
weimingz updated the diff for D35235: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions.

rebased. Please review. Thanks

Aug 7 2017, 11:51 AM

Aug 3 2017

weimingz added a reviewer for D36249: Mark tests that need intel 80-bit floats as x86-only: joerg.
Aug 3 2017, 11:51 AM
weimingz added a comment to D36249: Mark tests that need intel 80-bit floats as x86-only.

I tried to address it via checking pre-defined macros:
https://reviews.llvm.org/D31573

As long as the macros are defined correctly by clang, we don't need to worry about the specific target machine. How do you think about it?

I like the idea of a feature check, rather than a specific architecture check--that is clearly the right thing to do.

On the other hand, I would like to mark the test as unsupported and not run in that case, rather than running it, saying it passed, but not actually testing anything. That better reflects the state of the implementation. Unfortunately, I don't think that can be done with macro checks. So my preference would be this patch over D31573, but I would also find D31573 acceptable if it came to that.

Finally, 80-bit doubles are a bit of a historical artifact these days. Only x86 and m68k have them (and not even all m68Ks either). So I don't think it matters that much.

Aug 3 2017, 11:51 AM

Aug 2 2017

weimingz added a comment to D36249: Mark tests that need intel 80-bit floats as x86-only.

I tried to address it via checking pre-defined macros:
https://reviews.llvm.org/D31573

Aug 2 2017, 11:46 PM

Jul 31 2017

weimingz added a comment to D35970: Teach cc1as driver to accept ARM ropi/rwpi reloc model.

This looks like it'll get the build attributes wrong (since only PIC gets plumbed through to the backend). That's probably worse than simply rejecting the arguments.

Jul 31 2017, 4:02 PM
weimingz updated the diff for D35970: Teach cc1as driver to accept ARM ropi/rwpi reloc model.

add test case

Jul 31 2017, 3:05 PM

Jul 27 2017

weimingz created D35970: Teach cc1as driver to accept ARM ropi/rwpi reloc model.
Jul 27 2017, 6:04 PM

Jul 26 2017

weimingz added a comment to D35235: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions.

ping?

Jul 26 2017, 5:06 PM

Jul 18 2017

weimingz committed rL308404: Fix DebugLoc propagation for unreachable LoadInst.
Fix DebugLoc propagation for unreachable LoadInst
Jul 18 2017, 6:27 PM
weimingz closed D34639: Fix DebugLoc propagation for unreachable LoadInst by committing rL308404: Fix DebugLoc propagation for unreachable LoadInst.
Jul 18 2017, 6:27 PM

Jul 17 2017

weimingz updated the diff for D35235: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions.

rebased after reverting r307595 and moving __refstring header

Jul 17 2017, 6:10 PM

Jul 14 2017

weimingz updated the diff for D31220: [builtins][ARM] Select correct code fragments when compiling for Thumb1/Thum2/ARM ISA.

address the review comments by @peter.smith and @jamesduley

Jul 14 2017, 11:28 AM

Jul 13 2017

weimingz updated the diff for D31220: [builtins][ARM] Select correct code fragments when compiling for Thumb1/Thum2/ARM ISA.

rebased

Jul 13 2017, 11:18 AM

Jul 10 2017

weimingz created D35235: [libc++] Replace __sync_* functions with __libcpp_atomic_* functions.
Jul 10 2017, 6:32 PM
weimingz added a comment to D34918: [libc++] Refactoring __sync_* builtins; NFC.

I should use existing include/atomic_support.h. Will upload the patch shortly.

Jul 10 2017, 6:22 PM
weimingz updated the diff for D34639: Fix DebugLoc propagation for unreachable LoadInst.

simplify test case

Jul 10 2017, 5:34 PM
weimingz committed rL307595: [libc++] Refactoring __sync_* builtins; NFC (Reland).
[libc++] Refactoring __sync_* builtins; NFC (Reland)
Jul 10 2017, 2:38 PM
weimingz updated the diff for D34918: [libc++] Refactoring __sync_* builtins; NFC.

missed to upload the change to include __atomic_support header file

Jul 10 2017, 2:31 PM
weimingz committed rL307593: Revert "[libc++] Refactoring __sync_* builtins; NFC".
Revert "[libc++] Refactoring __sync_* builtins; NFC"
Jul 10 2017, 2:24 PM
weimingz committed rL307591: [libc++] Refactoring __sync_* builtins; NFC.
[libc++] Refactoring __sync_* builtins; NFC
Jul 10 2017, 2:03 PM
weimingz closed D34918: [libc++] Refactoring __sync_* builtins; NFC by committing rL307591: [libc++] Refactoring __sync_* builtins; NFC.
Jul 10 2017, 2:03 PM
weimingz retitled D34918: [libc++] Refactoring __sync_* builtins; NFC from [libc++] Avoid atomic built-ins for NO_THREADS build to [libc++] Refactoring __sync_* builtins; NFC.
Jul 10 2017, 1:41 PM

Jul 9 2017

weimingz added a comment to D34639: Fix DebugLoc propagation for unreachable LoadInst.

testcase?

Jul 9 2017, 6:13 AM