-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add LTO build option #505
Add LTO build option #505
Conversation
An old PR which I used as a base: WebAssembly#150 Co-Authored-by: Dan Gohman <[email protected]>
# LTO; no, full, or thin | ||
# Note: thin LTO here is just for experimentation. It has known issues: | ||
# - https://github.com/llvm/llvm-project/issues/91700 | ||
# - https://github.com/llvm/llvm-project/issues/91711 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to these issue I think you will find that any symbols that implement libcalls, or required by the libcall implemenation must currently be excluded from LTO. See https://github.com/emscripten-core/emscripten/blob/3de1b9091adbadc46706959bd97efa033214bc2c/tools/system_libs.py#L1007-L1020
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it still necessary after https://reviews.llvm.org/D71738? do you have a test case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i have excluded __cxa_atexit since then.
other things listed in your emscripten link seem like compiler-rt, which i don't have a plan to build with LTO for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think one issue is that compiler-rt can have transitive dependencies into libc. I imagine you will run into similar issues here once you start testing more extensively with LTO, but perhaps I'm wrong, or perhaps things have changed in some way.
Anyway, I guess its fine to land this and then fix issues as they come up in the field (which is basically what we did in emscripten).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i glanced at compiler-rt.
i couldn't find problematic transitive dependencies.
obvious dependencies like memset etc are covered by https://reviews.llvm.org/D71738.
This fixes a failure in wasi-sdk "make check". ("undefined symbol: __cxa_atexit" for ctors_dtors.c test)
wasi-sdk counterpart WebAssembly/wasi-sdk#424 |
can this land? |
closed by mistake and then reopened. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm. We can always add object to LIBC_NONLTO_OBJS later if we find any issues going forward.
Makefile
Outdated
@@ -627,6 +658,8 @@ $(SYSROOT_LIB)/libsetjmp.a: $(LIBSETJMP_OBJS) | |||
|
|||
$(PIC_OBJS): CFLAGS += -fPIC -fvisibility=default | |||
|
|||
$(LIBC_NONLTO_OBJS): CFLAGS += -fno-lto |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I wonder if we could instead filter out the -flto
flag instead of passing both -flto
and -fno-lto
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
cmake version WebAssembly/wasi-sdk#436 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An old PR which I used as a base:
#150