mstorsjo (Martin Storsjö)
User

Projects

User does not belong to any projects.

User Details

User Since
Jul 25 2016, 12:54 PM (81 w, 6 d)

Recent Activity

Sat, Feb 17

mstorsjo committed rL325433: [AArch64] Implement dynamic stack probing for windows.
[AArch64] Implement dynamic stack probing for windows
Sat, Feb 17, 6:30 AM
mstorsjo closed D42356: [AArch64] Implement dynamic stack probing for windows.
Sat, Feb 17, 6:30 AM
mstorsjo accepted D43412: Factor out common code from applySecRel functions..

LGTM, thanks!

Sat, Feb 17, 6:04 AM

Fri, Feb 16

mstorsjo committed rLLD325396: [COFF] Add support for ARM64 secrel relocations for add/load instructions.
[COFF] Add support for ARM64 secrel relocations for add/load instructions
Fri, Feb 16, 2:05 PM
mstorsjo committed rL325396: [COFF] Add support for ARM64 secrel relocations for add/load instructions.
[COFF] Add support for ARM64 secrel relocations for add/load instructions
Fri, Feb 16, 2:05 PM
mstorsjo closed D43287: [LLD] [COFF] Add support for ARM64 secrel relocations for add/load instructions.
Fri, Feb 16, 2:04 PM

Thu, Feb 15

mstorsjo added a comment to D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport.
In D43184#1009355, @rnk wrote:

The Qt bug is interesting, but I think we're doing the right thing here. C++ doesn't define any semantics for partially initialized objects. It's unclear if clang or GCC's way of doing things is better or not. With clang, you get to put the global in .bss, so it's not clear what makes for bigger code size.

Thu, Feb 15, 10:57 PM
mstorsjo updated the diff for D43287: [LLD] [COFF] Add support for ARM64 secrel relocations for add/load instructions.

Factorized the initial part of calculating the section relative offset.

Thu, Feb 15, 10:26 PM
mstorsjo added inline comments to D43287: [LLD] [COFF] Add support for ARM64 secrel relocations for add/load instructions.
Thu, Feb 15, 10:18 PM
mstorsjo added a comment to D43287: [LLD] [COFF] Add support for ARM64 secrel relocations for add/load instructions.

Ping @ruiu

Thu, Feb 15, 1:56 PM
mstorsjo added a comment to D42356: [AArch64] Implement dynamic stack probing for windows.

Ping @aemerson

Thu, Feb 15, 1:54 PM

Wed, Feb 14

mstorsjo added a reviewer for D43288: [AArch64] Add support for secrel add/load/store relocations for COFF: efriedma.
Wed, Feb 14, 2:15 PM
mstorsjo added a comment to D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport.
In D43184#1005258, @rnk wrote:

Do you think we should do something like local vftables for itanium instead? Can we assume all methods in the vtable will be exported by the DLL exporting the class?

Wed, Feb 14, 12:33 PM
mstorsjo created D43288: [AArch64] Add support for secrel add/load/store relocations for COFF.
Wed, Feb 14, 5:44 AM
mstorsjo retitled D43287: [LLD] [COFF] Add support for ARM64 secrel relocations for add/load instructions from [LLD] [COFF] Add support for secrel relocations for add/load instructions to [LLD] [COFF] Add support for ARM64 secrel relocations for add/load instructions.
Wed, Feb 14, 5:44 AM
mstorsjo created D43287: [LLD] [COFF] Add support for ARM64 secrel relocations for add/load instructions.
Wed, Feb 14, 5:34 AM

Mon, Feb 12

mstorsjo committed rL324937: [GlobalMerge] Allow merging of dllexported variables.
[GlobalMerge] Allow merging of dllexported variables
Mon, Feb 12, 1:16 PM
mstorsjo closed D43192: [GlobalMerge] Allow merging of dllexported variables.
Mon, Feb 12, 1:16 PM
mstorsjo added a comment to D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport.

FYI, binutils auto-import actually creates a fake IAT entry rather than using a dynamic initializer. I think it's actually a pretty cute trick. http://blog.omega-prime.co.uk/2011/07/04/everything-you-never-wanted-to-know-about-dlls/#how-auto-import-works has details. That only works when you're referencing an external imported symbol directly though, and breaks when you need an offset from the imported symbol.

Mon, Feb 12, 12:58 PM
mstorsjo created D43192: [GlobalMerge] Allow merging of dllexported variables.
Mon, Feb 12, 7:05 AM
mstorsjo created D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport.
Mon, Feb 12, 5:59 AM
mstorsjo updated the diff for D42356: [AArch64] Implement dynamic stack probing for windows.

Structured the code to easier allow adding a darwin specific version of stack probing without conflicting with the windows specific parts here. Added a "return false" in GlobalISel for windows for alloca, to make sure we invoke the proper codegen for this.

Mon, Feb 12, 5:23 AM

Fri, Feb 9

mstorsjo resigned from D38128: Handle COPYs of physregs better (regalloc hints).
Fri, Feb 9, 1:38 AM
mstorsjo accepted D38128: Handle COPYs of physregs better (regalloc hints).

So with the absolutely minimal performance regression in swifterror.ll and lack of response otherwise, I think I'm ok with giving it the LGTM for aarch64.

Fri, Feb 9, 12:44 AM

Wed, Feb 7

mstorsjo added a comment to D43005: [ARM] Error out on .arm assembler directives on windows.

I think we should first clarify that currently the only Windows on ARM support is Windows ARM NT (Windows ARM CE still does have both modes of execution). The important thing to note here is that although the CPU supports both modes of execution, the Windows ARM NT kernel does not guarantee the current mode will be preserved (that is, if you trap into the kernel in ARM mode, you are probably going to come out in Thumb mode and fault).

Wed, Feb 7, 11:40 AM
mstorsjo added a comment to D43005: [ARM] Error out on .arm assembler directives on windows.
Clearing it from there doesn't seem to be enough when assembling .s files from clang though.

Looks like the ARMSubtarget is not initialized for the assembler from clang. But it would be great if we could handle that in ARMSubtarget, rather than duplicating the Windows implies NoARM logic here.

Wed, Feb 7, 4:22 AM
mstorsjo created D43005: [ARM] Error out on .arm assembler directives on windows.
Wed, Feb 7, 2:06 AM

Mon, Feb 5

mstorsjo updated subscribers of D38128: Handle COPYs of physregs better (regalloc hints).

Yes, this looks like mostly no-op reorderings. I don't remember exactly what part I thought was a potential performance regression in swifterror.ll before - it moves one "mov" instruction (in two places) to before a branch, so potentially executing one instruction more than before. I would say it's most probably ok (and the gains in some of the other register shuffling tests would make it sound like a net gain in any case).

Mon, Feb 5, 6:07 AM

Thu, Feb 1

mstorsjo updated subscribers of D42641: [MinGW] Emit typeinfo locally for dllimported classes without key functions.

@hans I'd like to have this in 6.0 as well, to allow building Qt for windows as DLLs.

Thu, Feb 1, 11:35 PM
mstorsjo committed rC324059: [MinGW] Emit typeinfo locally for dllimported classes without key functions.
[MinGW] Emit typeinfo locally for dllimported classes without key functions
Thu, Feb 1, 10:24 PM
mstorsjo committed rL324059: [MinGW] Emit typeinfo locally for dllimported classes without key functions.
[MinGW] Emit typeinfo locally for dllimported classes without key functions
Thu, Feb 1, 10:24 PM
mstorsjo closed D42641: [MinGW] Emit typeinfo locally for dllimported classes without key functions.
Thu, Feb 1, 10:24 PM

Wed, Jan 31

mstorsjo added inline comments to D42641: [MinGW] Emit typeinfo locally for dllimported classes without key functions.
Wed, Jan 31, 11:35 PM
mstorsjo added inline comments to D42641: [MinGW] Emit typeinfo locally for dllimported classes without key functions.
Wed, Jan 31, 7:28 PM

Tue, Jan 30

mstorsjo updated the diff for D42641: [MinGW] Emit typeinfo locally for dllimported classes without key functions.

Adjusted the fix by moving the change into ShouldUseExternalRTTIDescriptor - this causes less changes to other tests. @majnemer - do you think this is better or worse than having the fix in isVTableExternal?

Tue, Jan 30, 1:53 PM
mstorsjo committed rL323811: [GlobalISel] Bail out on calls to dllimported functions.
[GlobalISel] Bail out on calls to dllimported functions
Tue, Jan 30, 11:54 AM
mstorsjo committed rL323810: [AArch64] Properly handle dllimport of variables when using fast-isel.
[AArch64] Properly handle dllimport of variables when using fast-isel
Tue, Jan 30, 11:54 AM
mstorsjo closed D42567: [AArch64] Properly handle dllimport of variables when using fast-isel.
Tue, Jan 30, 11:54 AM
mstorsjo closed D42568: [GlobalISel] Bail out on calls to dllimported functions.
Tue, Jan 30, 11:54 AM
mstorsjo updated subscribers of D42568: [GlobalISel] Bail out on calls to dllimported functions.

@hans And this one also would be good to backport.

Tue, Jan 30, 11:54 AM
mstorsjo updated subscribers of D42567: [AArch64] Properly handle dllimport of variables when using fast-isel.

@hans This would be good to have backported.

Tue, Jan 30, 11:54 AM
mstorsjo added a comment to D42567: [AArch64] Properly handle dllimport of variables when using fast-isel.

Ping @aemerson - can you give this an ack from a generic aarch64 target perspective - the windows side of it was already ok'd.

Tue, Jan 30, 10:47 AM

Mon, Jan 29

mstorsjo committed rL323725: [COFF] Remove the temporary file if not updating the import library.
[COFF] Remove the temporary file if not updating the import library
Mon, Jan 29, 11:27 PM
mstorsjo committed rLLD323725: [COFF] Remove the temporary file if not updating the import library.
[COFF] Remove the temporary file if not updating the import library
Mon, Jan 29, 11:27 PM
mstorsjo closed D42621: [LLD] [COFF] Remove the temporary file if not updating the import library.
Mon, Jan 29, 11:27 PM
mstorsjo added inline comments to D42659: [COFF] Clarify comment. NFC.
Mon, Jan 29, 1:47 PM
mstorsjo added inline comments to D42641: [MinGW] Emit typeinfo locally for dllimported classes without key functions.
Mon, Jan 29, 11:59 AM
mstorsjo updated the diff for D42641: [MinGW] Emit typeinfo locally for dllimported classes without key functions.

Remove a few accidentally leftover parts of the new testcase.

Mon, Jan 29, 5:32 AM
mstorsjo created D42641: [MinGW] Emit typeinfo locally for dllimported classes without key functions.
Mon, Jan 29, 5:28 AM

Sun, Jan 28

mstorsjo created D42621: [LLD] [COFF] Remove the temporary file if not updating the import library.
Sun, Jan 28, 4:52 AM

Sat, Jan 27

mstorsjo added a comment to D42603: [COFF] Update comment to reflect link.exe behavior. NFC.

LGTM. I confirmed this with link.exe with the test case from long-section-names.test. I don't remember what I originally tested, that the previous comment was based on - maybe it was just a mixup.

Sat, Jan 27, 3:56 AM

Fri, Jan 26

mstorsjo updated the diff for D42568: [GlobalISel] Bail out on calls to dllimported functions.

Don't skip GlobalISel altogether, but just bail out on dllimport function calls.

Fri, Jan 26, 2:47 AM
mstorsjo added a comment to D42568: [GlobalISel] Bail out on calls to dllimported functions.

However, the "return false;" in translateCall doesn't cause such fallbacking, but insteads makes the build abort with this error message:

LLVM ERROR: unable to translate instruction: call (in function: call_external)

Fri, Jan 26, 2:45 AM
mstorsjo added a comment to D42568: [GlobalISel] Bail out on calls to dllimported functions.

Hi Martin,

Do I understand correctly that this patch both has code to disable globalisel when targeting windows, and also when a function is marked as "dllimport"?
Wouldn't one of these checks be enough?
From your description, I would have thought that just the "dllimport" check would be enough?
I'm probably missing quite a bit of background info here - but I thought I'd ask to understand this better.

Fri, Jan 26, 1:56 AM
mstorsjo created D42568: [GlobalISel] Bail out on calls to dllimported functions.
Fri, Jan 26, 1:37 AM
mstorsjo created D42567: [AArch64] Properly handle dllimport of variables when using fast-isel.
Fri, Jan 26, 1:35 AM

Thu, Jan 25

mstorsjo committed rUNW323499: Don't enable _LIBUNWIND_BUILD_ZERO_COST_APIS if building the SJLJ APIs.
Don't enable _LIBUNWIND_BUILD_ZERO_COST_APIS if building the SJLJ APIs
Thu, Jan 25, 10:51 PM
mstorsjo committed rL323499: Don't enable _LIBUNWIND_BUILD_ZERO_COST_APIS if building the SJLJ APIs.
Don't enable _LIBUNWIND_BUILD_ZERO_COST_APIS if building the SJLJ APIs
Thu, Jan 25, 10:51 PM
mstorsjo closed D42555: [libunwind] Don't enable _LIBUNWIND_BUILD_ZERO_COST_APIS if building the SJLJ APIs.
Thu, Jan 25, 10:51 PM
mstorsjo created D42555: [libunwind] Don't enable _LIBUNWIND_BUILD_ZERO_COST_APIS if building the SJLJ APIs.
Thu, Jan 25, 1:05 PM

Wed, Jan 24

mstorsjo added a comment to D42356: [AArch64] Implement dynamic stack probing for windows.

For GlobalISel we haven't had to have very target specific code in the IRTranslator for this before. @qcolombet any opinion on whether we want to include target/ABI specific code into the IRTranslator? My feeling is that we want to avoid this, the alternative I can see is to introduce a new opcode for G_DYNALLOCA and lower that at isel.

Wed, Jan 24, 11:22 PM
mstorsjo committed rCRT323315: [builtins] Align addresses to cache lines in __clear_cache for aarch64.
[builtins] Align addresses to cache lines in __clear_cache for aarch64
Wed, Jan 24, 2:17 AM
mstorsjo updated subscribers of D42196: [compiler-rt] [builtins] Align addresses to cache lines in __clear_cache for aarch64.

@hans - I think this is a pretty simple/straightforward bugfix that might be worthy of backporting to 6.0.

Wed, Jan 24, 2:17 AM
mstorsjo committed rL323315: [builtins] Align addresses to cache lines in __clear_cache for aarch64.
[builtins] Align addresses to cache lines in __clear_cache for aarch64
Wed, Jan 24, 2:16 AM
mstorsjo closed D42196: [compiler-rt] [builtins] Align addresses to cache lines in __clear_cache for aarch64.
Wed, Jan 24, 2:16 AM
mstorsjo added a comment to D42196: [compiler-rt] [builtins] Align addresses to cache lines in __clear_cache for aarch64.

@peter.smith Would you care to approve this one, when there don't seem to be anybody else interested in it?

Wed, Jan 24, 2:10 AM
mstorsjo added a reviewer for D42196: [compiler-rt] [builtins] Align addresses to cache lines in __clear_cache for aarch64: peter.smith.
Wed, Jan 24, 2:09 AM

Tue, Jan 23

mstorsjo updated subscribers of D42127: [GlobalMerge] Don't merge dllexport globals.

@hans - can we backport this to the 6.0 branch? The usecase it fixes is "compiling Qt for Windows on ARM" (which previously fails when building with -O3). The fix in SVN r323307 probably requires merging SVN r322900 as well, to go without conflicts - it's a trivial testcase touch-up.

Tue, Jan 23, 10:45 PM
mstorsjo committed rL323308: [ARM] Call __chkstk for dynamic stack allocation in all windows environments.
[ARM] Call __chkstk for dynamic stack allocation in all windows environments
Tue, Jan 23, 10:41 PM
mstorsjo closed D42292: [ARM] Call __chkstk for dynamic stack allocation in all windows environments.
Tue, Jan 23, 10:41 PM
mstorsjo committed rL323307: [GlobalMerge] Don't merge dllexport globals.
[GlobalMerge] Don't merge dllexport globals
Tue, Jan 23, 10:41 PM
mstorsjo closed D42127: [GlobalMerge] Don't merge dllexport globals.
Tue, Jan 23, 10:41 PM
mstorsjo added a comment to D42292: [ARM] Call __chkstk for dynamic stack allocation in all windows environments.

Updated the summary/commit message as requested on irc.

Tue, Jan 23, 9:52 PM
mstorsjo updated the summary of D42292: [ARM] Call __chkstk for dynamic stack allocation in all windows environments.
Tue, Jan 23, 9:52 PM
mstorsjo added a comment to D42127: [GlobalMerge] Don't merge dllexport globals.

Wouldn't it be possible to merge multiple dllexport globals?

@x = dllexport global i32 0, align 4
@y = dllexport global i32 0, align 4
@z = global i32 0, align 4
@a = global i32 0, align 4

could still merge into:

@x = dllexport global i32 0, align 4
@z = global i32 0, align 4

even though technically we should be able to merge all of that into a single global and preserve the dllexport attribute.

Tue, Jan 23, 11:18 AM
mstorsjo added a comment to D42292: [ARM] Call __chkstk for dynamic stack allocation in all windows environments.

Does it match a cl intrinsic?

Tue, Jan 23, 9:49 AM
mstorsjo added a comment to D42292: [ARM] Call __chkstk for dynamic stack allocation in all windows environments.

I'm not sure that I follow how this is only for the alloca function. It is for an intrinsic, which just generally enables it. Does it match a cl intrinsic?

Tue, Jan 23, 9:44 AM
mstorsjo added a comment to D42196: [compiler-rt] [builtins] Align addresses to cache lines in __clear_cache for aarch64.

I guess this comes down to the interpretation of (begin, end] when you can only clear a cache line at a time. I think that this makes sense as it matches the powerpc64 below, Linux also follows this approach. I'm not sure how this is done on BSD and Darwin.

Tue, Jan 23, 3:24 AM
mstorsjo added a comment to D42127: [GlobalMerge] Don't merge dllexport globals.

Ping @john.brawn and @compnerd - does it look good to you now?

Tue, Jan 23, 1:14 AM

Mon, Jan 22

mstorsjo added a comment to D42196: [compiler-rt] [builtins] Align addresses to cache lines in __clear_cache for aarch64.

Ping @t.p.northover

Mon, Jan 22, 2:12 PM
mstorsjo added a comment to D42214: libcxx: Move Windows threading support into a .cpp file..

LGTM now, but I'll let @smeenai give it the proper approval.

Mon, Jan 22, 1:22 PM

Sun, Jan 21

mstorsjo created D42356: [AArch64] Implement dynamic stack probing for windows.
Sun, Jan 21, 12:53 PM

Sat, Jan 20

mstorsjo added inline comments to D42214: libcxx: Move Windows threading support into a .cpp file..
Sat, Jan 20, 9:50 AM
mstorsjo added inline comments to D42214: libcxx: Move Windows threading support into a .cpp file..
Sat, Jan 20, 4:08 AM
mstorsjo committed rLLD323036: [COFF] Keep the underscore on exported decorated stdcall functions in MSVC mode.
[COFF] Keep the underscore on exported decorated stdcall functions in MSVC mode
Sat, Jan 20, 3:47 AM
mstorsjo committed rL323036: [COFF] Keep the underscore on exported decorated stdcall functions in MSVC mode.
[COFF] Keep the underscore on exported decorated stdcall functions in MSVC mode
Sat, Jan 20, 3:47 AM
mstorsjo closed D41632: [LLD] [COFF] Keep the underscore on exported decorated stdcall functions.
Sat, Jan 20, 3:47 AM
mstorsjo committed rL323035: [COFF] Keep the underscore on exported decorated stdcall functions in MSVC mode.
[COFF] Keep the underscore on exported decorated stdcall functions in MSVC mode
Sat, Jan 20, 3:47 AM
mstorsjo closed D41631: [COFF] Keep the underscore on exported decorated stdcall functions.
Sat, Jan 20, 3:47 AM

Jan 19 2018

mstorsjo added a comment to D42292: [ARM] Call __chkstk for dynamic stack allocation in all windows environments.

What is the motivation for this change? If you are trying to enable this for MinGW, that is fine, but I'm not sure if we should try to catch the VLA issues in the frontend. I believe that on x86_64, we also disallow the VLAs as Microsoft does not permit them there, but @rnk can correct me if I'm wrong on that.

Jan 19 2018, 11:51 AM
mstorsjo updated the diff for D42292: [ARM] Call __chkstk for dynamic stack allocation in all windows environments.

Simplified by using Subtarget->isTargetWindows() instead of Subtaget->getTargetTriple().isOSWindows().

Jan 19 2018, 5:57 AM
mstorsjo added a comment to D41631: [COFF] Keep the underscore on exported decorated stdcall functions.

Ping @ruiu @rnk - the corresponding change for LLD was already OK'd by Rui in D41632, but these two need to go together.

Jan 19 2018, 4:21 AM
mstorsjo created D42292: [ARM] Call __chkstk for dynamic stack allocation in all windows environments.
Jan 19 2018, 4:20 AM

Jan 18 2018

mstorsjo committed rCRT322928: [builtins] Use FlushInstructionCache on windows on aarch64 as well.
[builtins] Use FlushInstructionCache on windows on aarch64 as well
Jan 18 2018, 11:38 PM
mstorsjo committed rL322928: [builtins] Use FlushInstructionCache on windows on aarch64 as well.
[builtins] Use FlushInstructionCache on windows on aarch64 as well
Jan 18 2018, 11:38 PM
mstorsjo closed D42197: [compiler-rt] [builtins] Use FlushInstructionCache on windows on aarch64 as well.
Jan 18 2018, 11:38 PM
mstorsjo updated the diff for D42127: [GlobalMerge] Don't merge dllexport globals.

Added a testcase to show that normal globals still are merged.

Jan 18 2018, 11:23 PM
mstorsjo updated the diff for D42127: [GlobalMerge] Don't merge dllexport globals.

Changed to explicitly check for the dllexport attribute.

Jan 18 2018, 1:37 PM
mstorsjo committed rL322900: [test] Actually check the common parts in CodeGen/ARM/global-merge-external.ll..
[test] Actually check the common parts in CodeGen/ARM/global-merge-external.ll.
Jan 18 2018, 1:23 PM
mstorsjo closed D42126: [test] Actually check the common parts in CodeGen/ARM/global-merge-external.ll. NFC..
Jan 18 2018, 1:23 PM