[gn] Add option to use clang-cl for specific assembly files on Windows |
|||
Issue descriptionThe issue: Any .S file added to a sources array in BUILD.gn is automatically assembled by MASM on all Windows builds. That has two main drawbacks: 1) MASM can be very slow [0]; and 2) we are forced to use the MASM assembly dialect even clang Windows builds. We (V8) currently use a workaround to force compilation through clang-cl on Windows by wrapping the generated assembly in a .cc file containing inline assembly (with an __asm__() statement). That, of course, ended up exposing issues elsewhere [1]. Other folks have also run into this before [2]. Potential solution: Provide an option to specify assembly source files in BUILD.gn s.t. they are passed to clang-cl on Windows clang builds. [0] https://crbug.com/v8/8475 [1] https://crbug.com/v8/8502#c14 [2] https://crbug.com/762167
,
Nov 30
I'm not sure this should be a gn thing. Long term, we want to have some masm-compatible thing in llvm land. rnk, hans: WDYT about making clang-cl accept .S and .asm files and running -cc1as for .S files and shell out to ml(64).exe for .asm files until we have our own masm assembler? Then we could set the asm program to clang-cl and things would mostly work (...except for in cross builds).
,
Nov 30
Could we set up the build to use regular clang with some appropriate flags for the .S files? That doesn't solve the .asm problem, but it might solve V8's issue?
,
Nov 30
gn has an "asm" tool that it uses for both .S and .asm files (https://cs.chromium.org/chromium/src/build/toolchain/win/BUILD.gn?q=file:toolchain+file:win&sq=package:chromium&g=0&l=216)
,
Nov 30
Okay, I'm not opposed to having clang-cl handle these, but I'm not sure I have cycles to work on it right now.
,
Nov 30
I didn't mean to say you should do this! Mostly wanted to get feedback on the idea to shell out to ml from clang-cl for a while. (As I said, I'm not sure what that would mean for cross builds -- since we'd move the v8 file to a .S file then, I think we wouldn't get additional ml invocations to what we already have, so it shouldn't be worse -- so it'd be fine from that PoV)
,
Jan 10
|
|||
►
Sign in to add a comment |
|||
Comment 1 by jgruber@chromium.org
, Nov 30