Page MenuHomePhabricator

hjl.tools (H.J Lu)
User

Projects

User does not belong to any projects.

User Details

User Since
Feb 11 2015, 7:59 AM (302 w, 5 d)

Recent Activity

Yesterday

hjl.tools added a comment to D16474: Use PC-relative address for x32 TLS address.

LLVM ERROR: Cannot select: 0x29507a0: ch,glue = X86ISD::TLSADDR 0x28fc140, TargetGlobalTLSAddress:i32<i32* @x> 0 [TF=7]

This still happens with current LLVM. If we can push the fix for that first (presumably you fixed this already on your old branch), we could then include your test case in this diff.

Sun, Nov 29, 6:08 AM · Restricted Project

Sat, Nov 28

hjl.tools added a comment to D16474: Use PC-relative address for x32 TLS address.

My old x32 patches are at https://github.com/hjl-tools/llvm-x32-old/tree/hjl/x32/2016-09-01

Sat, Nov 28, 7:48 AM · Restricted Project

Sat, Nov 14

hjl.tools added a comment to D91338: [X86] Zero-extend pointers to i64 for x86_64.

It is required for ILP32 since many system calls are shared between ILP32 and LP64.
Here is my x32 port from 2016.

Thanks H.J. It's amazing you already did many works on x32 support. But these patches seem not been merged to mainline. What's the reason for not merging them? Does that mean the trunk code still has some flaws on x32 ABI supporting?

Sat, Nov 14, 6:51 PM · Restricted Project
hjl.tools added a comment to D91338: [X86] Zero-extend pointers to i64 for x86_64.

Hi Harald, thanks for thoroughly answering my questions. I still have doubts intention of this patch. Is there any bug related to it?

I run an x32 system. Things work well for things built with GCC, but break badly when using LLVM, because the ABI as implemented is incompatible between GCC and LLVM, as GCC-generated code will sometimes assume that the high bits of pointer parameters have been zeroed out as required by the ABI. This is especially visible when using Rust applications, as the Rust compiler is LLVM-based but most of the rest of my system is built with GCC. Pretty much any non-trivial Rust application crashes, for instance ripgrep, or the Rust compiler itself.

IMHO, the ILP32 mode is designed for performance which always assumes the address bit 63~32 all zero and uses 32 bits register to reduce code size.

Sat, Nov 14, 7:04 AM · Restricted Project

May 19 2020

hjl.tools added a comment to D79617: Add cet.h for writing CET-enabled assembly code.

I would like a specification for this header to be added somewhere. We shouldn't be implementing random things with no specification. (Suppose someone claims that our <cet.h> is wrong in some way. How would we know whether they're right?)

Ideally, I'd also like this header to be installed somewhere where we look for assembler-with-cpp preprocessing but not for regular compilation; it doesn't make sense to me to pollute the header namespace for all C and C++ compilations with a header that is not meaningful in C and C++. But knowing whether that change is correct depends on having, you know, a specification.

May 19 2020, 6:43 PM · Restricted Project

May 11 2020

hjl.tools added a comment to D79617: Add cet.h for writing CET-enabled assembly code.

Refine the Macro _CET_ENDBR

May 11 2020, 5:19 AM · Restricted Project

May 10 2020

hjl.tools added inline comments to D79617: Add cet.h for writing CET-enabled assembly code.
May 10 2020, 9:17 PM · Restricted Project
hjl.tools added inline comments to D79617: Add cet.h for writing CET-enabled assembly code.
May 10 2020, 7:09 PM · Restricted Project

May 9 2020

hjl.tools added inline comments to D79617: Add cet.h for writing CET-enabled assembly code.
May 9 2020, 4:45 AM · Restricted Project

May 8 2020

hjl.tools added inline comments to D79617: Add cet.h for writing CET-enabled assembly code.
May 8 2020, 6:49 PM · Restricted Project
hjl.tools added inline comments to D79617: Add cet.h for writing CET-enabled assembly code.
May 8 2020, 4:15 AM · Restricted Project
hjl.tools added inline comments to D79617: Add cet.h for writing CET-enabled assembly code.
May 8 2020, 4:15 AM · Restricted Project

Apr 21 2020

hjl.tools added a comment to D78564: [i386] Modify the alignment of __m128/__m256/__m512 vector type according i386 abi..

I'm not sure this is right. _m512 is just a typedef to a 64 byte vector_size attribute. This patch changes the behavior of using 64 byte vector_size on an sse/avx target. Prior to avx512 existing an avx target would pass a 512 bit vector 32 byte aligned. It does't make sense to me to change the alignment on an avx target just because avx512 exists, but isn't enabled.

If we use an library function which passing __m512 on stack(such as variadic function) compiled with avx512 but the caller compiled without avx512, this will cause run fail. But actually, when parameters passed by registers, it will cause run fail too because caller and callee use different register. Therefore, it is hard to say whether it is reasonable to align to 64 bytes.

Apr 21 2020, 6:57 PM

Apr 9 2020

hjl.tools added inline comments to D77124: Handle CET for -exception-model sjlj.
Apr 9 2020, 4:51 AM · Restricted Project

Apr 2 2020

hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

Look good to me.

Apr 2 2020, 6:27 PM · Restricted Project
hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

It looks very confusing. Can you create a diff against master branch, not your last change?

Apr 2 2020, 10:17 AM · Restricted Project
hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
  1. Sync with HJ's large code changes in https://github.com/hjl-tools/llvm-project/commit/6a85ba472143c91e5686e1f0faf7fea7b4f0e350
  2. Add Eli's test in https://bugs.llvm.org/show_bug.cgi?id=45364 to llc test and JIT test.

For Large code model:
The compiler is required to use the movabs instruction, as in the medium code model, even for dealing with addresses inside the text section.
Additionally, indirect branches are needed when branching to addresses whose offset from the current instruction pointer is unknown.

Apr 2 2020, 8:06 AM · Restricted Project

Mar 31 2020

hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

I find your patch will not deal with internal function.
I tested GCC, It really will generate endbr for static functions:

gcc version 9.3.1 20200317 (Red Hat 9.3.1-1) (GCC)
 [xiangzh1@gnu-tgl-1 ~/tmp]$cat t.c
extern int foo2(int a);

extern int foo2(int a)
{
  return a*6;
}

static int foo3(int a)
{
  return a*7;
}

int foo(int a){
//  int (*pf3)(int) = foo;
//  int b = foo2(a) +foo3(a) + pf3(a);
  int b = foo2(a) +foo3(a);
  return b;
}
 [xiangzh1@gnu-tgl-1 ~/tmp]$
[xiangzh1@gnu-tgl-1 ~/tmp]$gcc -fcf-protection t.c -S -o t.s
Mar 31 2020, 8:55 PM · Restricted Project
hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

@efriedma Put the https://bugs.llvm.org/show_bug.cgi?id=45364 test into X86/indirect-branch-tracking.ll @test5

Mar 31 2020, 10:33 AM · Restricted Project

Mar 30 2020

hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

If "1 Check CET in JIT instead of checking -fcf-protection-branch" can't let VNC passed. The crash must happen at "Take address of a internal function."

This is not a IBT problem only for JIT, but also the static llvm compiler, e.g. llc.
And it may unable to track these calling through function address, because these function address may be calculated out in runtime or written in a big table.

Mar 30 2020, 4:50 AM · Restricted Project

Mar 29 2020

hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

2, Do you mean here we need add JIT test for this patch ? Check endbr in JIT generated code?

My changes fixed the VNC crash. But there is no testcase to show why my patches are needed.

Your tests failed on CET machine
and the existing llvm unit tests also failed the on the CET machine
They are the same reason for lack of endbr* in JIT.
So I think the existing llvm unit tests is enough for this patch.

Mar 29 2020, 8:52 PM · Restricted Project
hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

Please take a look at

https://gitlab.freedesktop.org/mesa/mesa

to see how LLVM JIT is used and extract a testcase from it.

1, Does it in your commits? I find 2 your commits without the JIT tests.

Mar 29 2020, 7:15 PM · Restricted Project
hjl.tools added a comment to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).

Please take a look at

Mar 29 2020, 4:46 AM · Restricted Project

Mar 28 2020

hjl.tools added inline comments to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Mar 28 2020, 4:08 PM · Restricted Project
hjl.tools added inline comments to D76900: Enable IBT(Indirect Branch Tracking) in JIT with CET(Control-flow Enforcement Technology).
Mar 28 2020, 3:46 AM · Restricted Project

Feb 5 2020

hjl.tools added a comment to D74006: [MC][ELF] Make linked-to symbol name part of ELFSectionKey.
.section .foo,"o",@progbits,foo  # first in the output section .foo due to stable sort
.byte 0

.section .foo,"o",@progbits,bar  # second
.byte 1

This is what lld currently does. It will be nice to get a sign-up from GNU ld. An alternative choice is that users should not rely on the order. I'm inclined to define an order here.

Feb 5 2020, 10:15 AM · Restricted Project

Mar 7 2019

hjl.tools added a comment to D58102: Support X86 Control-flow Enforcement Technology (CET) in LLD.

@xiangzhangllvm, a question for you not directly related to the patch but I suspect you might be best suited to find an answer: how do we test CET support today? We started trying to add CET to FreeBSD some time ago but have no way to test any work that we do.

Mar 7 2019, 7:48 PM · Restricted Project, lld

Mar 1 2019

hjl.tools added a comment to D58102: Support X86 Control-flow Enforcement Technology (CET) in LLD.

Add -z force-cet option to force enable CET.
But if we do not use this option, CET will also try to work unless meet the conditions of no satisfaction.

Mar 1 2019, 4:41 AM · Restricted Project, lld

Feb 28 2019

hjl.tools committed rGfadb22f4e2d6: Revert "Revert "[sanitizers] Restore internal_readlink for x32"" (authored by hjl.tools).
Revert "Revert "[sanitizers] Restore internal_readlink for x32""
Feb 28 2019, 11:34 AM
hjl.tools created D58788: Revert "Revert "[sanitizers] Restore internal_readlink for x32"".
Feb 28 2019, 9:54 AM · Restricted Project, Restricted Project

Feb 27 2019

hjl.tools added a comment to D58102: Support X86 Control-flow Enforcement Technology (CET) in LLD.

Thanks for putting this feature forward. I've not had a chance to go through everything in detail but I thought it would be important to mention that AArch64 has a similar set of features (Pointer Authentication PAC and Branch Target Identification BTI) that are going to use .note.gnu.property sections with GNU_PROPERTY_AARCH64_FEATURE_1_AND (same meaning as GNU_PROPERTY_X86_FEATURE_1_AND), with two associated feature bits GNU_PROPERTY_AARCH64_FEATURE_1_BTI and GNU_PROPERTY_AARCH64_FEATURE_1_PAC. AArch64 does need a modified PLT entry to make this work but it doesn't use a .splt, in effect an extra instruction at the top of the PLT if BTI is used and one at the end if PAC is used, or both if both BTI and PAC are needed. Given that we will have at least two targets implementing a similar mechanism but with target specific details then we'll either need to make it my responsibility to generalise the .note.gnu.property implementation so that it can support both AArch64 and X86, or we make it generic from the start. The main difference for AArch64 is that there are two independent feature bits to track.

In the case of AArch64 it is important for the program loader to only enable the BTI/PAC feature for the process if the whole program has been compiled/assembled to support it. Our prior experience with assembler files in particular is that it is very easy to get a single .s file added to a build that is harmless but doesn't have the .note.gnu.property set properly and a single one of these would be enough to clear all the features. Our thoughts were to add a command line option to force generation of the appropriate PLTs and the .note.gnu.property in the output file but to warn if an input file doesn't have the .note.gnu.property flag.

Feb 27 2019, 9:58 AM · Restricted Project, lld

Feb 21 2019

hjl.tools added a comment to D58413: [sanitizers] Restore internal_readlink for x32.
In D58413#1406201, @rnk wrote:

Of course the test fails, this always returns 0. Recommitting with the test disabled on Windows seems reasonable.

Feb 21 2019, 11:57 AM · Restricted Project, Restricted Project
hjl.tools added a comment to D58413: [sanitizers] Restore internal_readlink for x32.

It looks like that ReadBinaryNameCached doesn't work on Windows.
Someone who is familiar with Windows should take a look.

Feb 21 2019, 9:19 AM · Restricted Project, Restricted Project

Feb 20 2019

hjl.tools committed rG6716f4af81f6: [sanitizers] Restore internal_readlink for x32 (authored by hjl.tools).
[sanitizers] Restore internal_readlink for x32
Feb 20 2019, 3:43 AM

Feb 19 2019

hjl.tools updated the diff for D58413: [sanitizers] Restore internal_readlink for x32.
Feb 19 2019, 5:58 PM · Restricted Project, Restricted Project
hjl.tools added a comment to D58413: [sanitizers] Restore internal_readlink for x32.

See:

Feb 19 2019, 3:47 PM · Restricted Project, Restricted Project
hjl.tools created D58413: [sanitizers] Restore internal_readlink for x32.
Feb 19 2019, 3:38 PM · Restricted Project, Restricted Project

Nov 5 2018

hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

With both 3.3 and trunk (I don't have a 7.0 handy; I can build it if it would be helpful):

Please try clang 2.6 on both testcases.

From the releases:

23 Oct 2009 2.6

... why would you care about a 9 year old version of clang?

Nov 5 2018, 9:45 AM

Oct 31 2018

hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

With both 3.3 and trunk (I don't have a 7.0 handy; I can build it if it would be helpful):

Oct 31 2018, 3:30 PM
hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

No, AVX512 wasn't even announced when clang 3.3 came out.

Oct 31 2018, 1:27 PM
hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

I just tried clang 3.3, and as far as I can tell it behaves the same way as trunk.

If the argument is that we should be compatible with gcc on Linux, that's fine, but we should explicitly state that in a comment.

Oct 31 2018, 1:17 PM
hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

The ABI document before AVX was introduced didn't say anything at all about 256-bit vectors. So we're talking about compatibility with some other compiler. Which compiler?

Oct 31 2018, 12:46 PM
hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

Whatever you call it, the question remains; what specification and/or compiler are we trying to be compatible with?

Oct 31 2018, 12:24 PM
hjl.tools added a comment to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..

As far as I know, according to the ABI docs, it's impossible to return a 256-bit vector from a function if AVX is disabled.

Given that we aren't rejecting the testcase, we're effectively implementing a new "no-AVX" ABI variant. That variant is not defined anywhere, so we might as well pick the fastest convention, returning the value in registers. I'm not sure why you would want to return the vector in memory instead.

Oct 31 2018, 12:17 PM
hjl.tools added inline comments to D53919: [X86] Don't allow illegal vector types to return by direct value on x86-64..
Oct 31 2018, 2:56 AM

Jul 20 2018

hjl.tools updated the diff for D49608: Mark REAL(swapcontext) with indirect_return attribute on x86.

Remove the extra ")".

Jul 20 2018, 12:17 PM
hjl.tools updated the diff for D49608: Mark REAL(swapcontext) with indirect_return attribute on x86.

Added a __ has_attribute compatibility definition.

Jul 20 2018, 11:54 AM
hjl.tools created D49608: Mark REAL(swapcontext) with indirect_return attribute on x86.
Jul 20 2018, 10:33 AM

May 23 2018

hjl.tools added a comment to D47281: sanitizer: Use pre-computed size of struct ustat for Linux.

Can you check it in for me? Thanks.

May 23 2018, 3:57 PM
hjl.tools abandoned D47165: sanitizer: Don't intercept ustat for Linux.

Replaced by

May 23 2018, 2:02 PM
hjl.tools created D47281: sanitizer: Use pre-computed size of struct ustat for Linux.
May 23 2018, 2:00 PM
hjl.tools added a comment to D47165: sanitizer: Don't intercept ustat for Linux.

I tested it on Fedora 28 which has glibc 2.27. There is no regression, probably because there is no test.
We can a definition of sizeof(struct ustat) to sanitizer_common/sanitizer_platform_limits_posix.cc, which
doesn't depend on <sys/ustat.h>.

May 23 2018, 9:15 AM

May 22 2018

hjl.tools retitled D47165: sanitizer: Don't intercept ustat for Linux from [PATCH] sanitizer: Don't intercept ustat for Linux to sanitizer: Don't intercept ustat for Linux.
May 22 2018, 6:20 AM

May 21 2018

hjl.tools created D47165: sanitizer: Don't intercept ustat for Linux.
May 21 2018, 3:29 PM

Apr 30 2018

hjl.tools added inline comments to D46181: [X86][CET] Shadow stack fix for setjmp/longjmp.
Apr 30 2018, 6:12 AM

Feb 17 2018

hjl.tools added a comment to D43383: [llvm-mc] - Produce R_X86_64_PLT32 for "call/jmp foo"..

Does this change add reference to _GLOBAL_OFFSET_TABLE_?

Feb 17 2018, 6:43 AM

Oct 15 2017

hjl.tools added a comment to D38907: Give .note.gnu.build-id section alignment 4.

See:

Oct 15 2017, 6:17 PM · lld

Mar 13 2017

hjl.tools added a comment to D30049: x86 interrupt calling convention: re-align stack pointer on 64-bit if an error code was pushed.

No, there is no need to realign stack in 64-bit mode.

I'm not sure if I understand you correctly. Yes, there is no need to dynamically realign the stack in 64-bit mode since the CPU aligns the stack on a 16 byte boundary on interrupt entry. However, for some exceptions, the CPU pushes an 8 byte error code afterwards. In that case it is necessary to subtract another 8 bytes from RSP to restore the 16-byte alignment.

Mar 13 2017, 11:23 AM

Feb 21 2017

hjl.tools added a comment to D30049: x86 interrupt calling convention: re-align stack pointer on 64-bit if an error code was pushed.

No, there is no need to realign stack in 64-bit mode.

Feb 21 2017, 8:45 AM

Aug 16 2016

hjl.tools updated the diff for D23575: Preserve BasePtr for LEA64_32r .

Updated with comments from Michael.

Aug 16 2016, 1:01 PM
hjl.tools retitled D23575: Preserve BasePtr for LEA64_32r from to Preserve BasePtr for LEA64_32r .
Aug 16 2016, 12:10 PM

Aug 8 2016

hjl.tools added a comment to D22045: [X86] Support of no_caller_saved_registers attribute (Clang part).

For what it is worth, this certainly seems to be misnamed. By nature, if it doesn't preserve at least the stack pointer, there is no way to recover on return, right?

This is the best name we came up with and has been implemented in GCC.

What version of GCC supports this attribute? I tried 6.1.0 and it is unknown there.

Aug 8 2016, 8:50 AM
hjl.tools added a comment to D22045: [X86] Support of no_caller_saved_registers attribute (Clang part).

For what it is worth, this certainly seems to be misnamed. By nature, if it doesn't preserve at least the stack pointer, there is no way to recover on return, right?

Aug 8 2016, 8:37 AM

Aug 3 2016

hjl.tools added a comment to D23126: lld: Add EM_IAMCU support .
In D23126#504970, @ruiu wrote:

LGTM

Aug 3 2016, 11:25 AM · lld
hjl.tools retitled D23126: lld: Add EM_IAMCU support from to lld: Add EM_IAMCU support .
Aug 3 2016, 11:13 AM · lld

Jul 26 2016

hjl.tools added inline comments to D22827: [test/gold] Add gold test subdirectory tests needing v1.12 (or higher).
Jul 26 2016, 1:36 PM

Jul 25 2016

hjl.tools added a comment to D22045: [X86] Support of no_caller_saved_registers attribute (Clang part).

no_caller_saved_registers attribute can be used with any calling conventions.

Jul 25 2016, 8:15 AM
hjl.tools added inline comments to D22044: [X86] Support of no_caller_saved_registers attribute (LLVM part).
Jul 25 2016, 8:12 AM

Jul 12 2016

hjl.tools added inline comments to D22288: ldd: Add GotEntrySize/GotPltEntrySize to ELF target .
Jul 12 2016, 5:40 PM · lld
hjl.tools updated D22268: lld: Add -m elf32_x86_64 .
Jul 12 2016, 4:13 PM · lld
hjl.tools retitled D22288: ldd: Add GotEntrySize/GotPltEntrySize to ELF target from to ldd: Add GotEntrySize/GotPltEntrySize to ELF target .
Jul 12 2016, 4:07 PM · lld
hjl.tools retitled D22287: lld: Add ILP32 support to X86_64TargetInfo from to lld: Add ILP32 support to X86_64TargetInfo .
Jul 12 2016, 4:05 PM · lld
hjl.tools updated the diff for D22268: lld: Add -m elf32_x86_64 .

This patches fixes PLTREL. But it doesn't generate working x32 binaries.

Jul 12 2016, 4:02 PM · lld
hjl.tools retitled D22268: lld: Add -m elf32_x86_64 from to lld: Add -m elf32_x86_64 .
Jul 12 2016, 10:22 AM · lld

May 15 2016

hjl.tools added a comment to D20272: [ELF] - Support of compressed input sections implemented..

Until the content is copied to the output, I think we don't have to uncompress inputs. Do you think you can do it lazily?

May 15 2016, 8:15 AM

May 6 2016

hjl.tools updated the diff for D16474: Use PC-relative address for x32 TLS address.
May 6 2016, 1:55 PM · Restricted Project
hjl.tools added a comment to D19995: Optimize access to global variable references in PIE mode when linker supports copy relocations for PIE.

Is this still a problem with linkers which can convert load via GOT slot into load
immediate?

May 6 2016, 5:54 AM

Apr 27 2016

hjl.tools added a comment to D19528: [ELF] - Implemented -z combrelocs/nocombreloc..

I have found -z nocombreloc useful to debug ld and ld.so.

This can be really one-line-easy to add in lld, if restoring the original
order of relocations can be useful for something.
But again, gold does ignore that option, so it seems usecase
is very specific.

Apr 27 2016, 5:30 AM
hjl.tools added a comment to D19528: [ELF] - Implemented -z combrelocs/nocombreloc..

I have found -z nocombreloc useful to debug ld and ld.so.

Apr 27 2016, 5:01 AM

Apr 26 2016

hjl.tools added a comment to D19125: Enable __float128 on X86 and SystemZ.

Should it be handled similar to int128? Only targets which support float128
override hasFloat128Type without adding HasFloat128.

Apr 26 2016, 5:33 AM

Apr 14 2016

hjl.tools added a comment to D19040: Remove unnecessary load via GOT when accessing globals with PIE in x86_64.

Does it fix

Apr 14 2016, 3:59 PM
hjl.tools added a comment to D19125: Enable __float128 on X86 and SystemZ.

The current x86 psABIs are available from

Apr 14 2016, 10:51 AM
hjl.tools added a comment to D19125: Enable __float128 on X86 and SystemZ.

Why not enable __float128 on Linux/i386, which is defined in
the current i386 psABI?

Apr 14 2016, 10:43 AM

Mar 29 2016

hjl.tools added a comment to D18566: [x86] use SSE/AVX ops for non-zero memsets (PR27100).

Oops. I meant

Mar 29 2016, 1:19 PM
hjl.tools added a comment to D18566: [x86] use SSE/AVX ops for non-zero memsets (PR27100).

For 16-byte memset, we can generate

Mar 29 2016, 1:16 PM

Mar 11 2016

hjl.tools added a comment to D18091: ELF: Implement --build-id..

FYI, here is the spec for .note.gnu.build-id section:

Mar 11 2016, 12:02 PM

Feb 4 2016

hjl.tools added a comment to D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union.

Empty struct/union should be passed and returned as void for all IA psABs.

Feb 4 2016, 10:26 AM
hjl.tools added a comment to D16886: Fix struct __emutls_control to match GCC.

Can you check it in for me? Thanks.

Feb 4 2016, 9:58 AM
hjl.tools retitled D16886: Fix struct __emutls_control to match GCC from to Fix struct __emutls_control to match GCC.
Feb 4 2016, 7:43 AM

Feb 3 2016

hjl.tools added a comment to D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union.

I am planning to update i386, x86-64 and IA MCU psABIs to address how to
pass and return C++ empty class after resolving:

Feb 3 2016, 12:49 PM

Feb 2 2016

hjl.tools added a comment to D16805: Cast the fifth arg to mremap to void * .

Please check it in for me. Thanks.

Feb 2 2016, 10:19 AM
hjl.tools added a comment to D16808: [MCU] PR26438: Fix assertion failure on function returning an empty struct or union.

Why should empty structs and unions) be return in memory? I don't remember
I called for it in MCU psABI.

Feb 2 2016, 9:13 AM
hjl.tools retitled D16805: Cast the fifth arg to mremap to void * from to Cast the fifth arg to mremap to void * .
Feb 2 2016, 7:44 AM

Feb 1 2016

hjl.tools added a comment to D16779: Fix attribute((mode([word|unwind_word]))) for x32 .

Yes, please. Thanks.

Feb 1 2016, 10:40 AM
hjl.tools retitled D16779: Fix attribute((mode([word|unwind_word]))) for x32 from to Fix attribute((mode([word|unwind_word]))) for x32 .
Feb 1 2016, 10:28 AM

Jan 25 2016

hjl.tools added a comment to D16474: Use PC-relative address for x32 TLS address.

Since llvm doesn't support TLS for x32:

Jan 25 2016, 1:07 PM · Restricted Project
hjl.tools added a comment to D16469: Pass --wrap=pthread_create to linker for -fsplit-stack.

Can you check it in for me? Thanks.

Jan 25 2016, 10:09 AM

Jan 22 2016

hjl.tools updated the diff for D16469: Pass --wrap=pthread_create to linker for -fsplit-stack.

Add a testcase.

Jan 22 2016, 1:26 PM
hjl.tools updated the diff for D16474: Use PC-relative address for x32 TLS address.

Use Subtarget->is32Bit()) instead. The full function now is:

Jan 22 2016, 12:27 PM · Restricted Project
hjl.tools retitled D16474: Use PC-relative address for x32 TLS address from to Use PC-relative address for x32 TLS address .
Jan 22 2016, 10:45 AM · Restricted Project