This is an archive of the discontinued LLVM Phabricator instance.

[builtins] Move X86 common files to a subdirectory
Needs ReviewPublic

Authored by kongyi on Oct 31 2019, 3:05 PM.

Details

Summary

With 8ea148dc0cbf, we can clean up the root directory of crt builtins by moving x86 common source files to a subdirectory.

Diff Detail

Event Timeline

kongyi created this revision.Oct 31 2019, 3:05 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptOct 31 2019, 3:05 PM
Herald added subscribers: llvm-commits, Restricted Project, mgorny. · View Herald Transcript

@kongyi Hmm we have both x86_common/floatdixf.c and x86_64/floatdixf.c. I think both x86_64h_SOURCES and x86_64_SOURCES will end up with both x86_common/floatdixf.c and x86_64/floatdixf.c due to...

set(x86_64h_SOURCES ${x86_64h_SOURCES} ${x86_ARCH_SOURCES})
set(x86_64_SOURCES ${x86_64_SOURCES} ${x86_ARCH_SOURCES})

I don't think the filtering algorithm (removing generic builtin implementations in favour of architecture specific implementations) handles this case. Due to both sources being in sub directories they are considered to both be architecture specific implementations.
If I'm right it should mean that with this patch running ninja check-builtins should result in an error due to me relanding 23a33d450b9a426eae7094b16472f8a51fb5488a, i.e. when lit runs we should detect that there is more than one implementation of floatdixf.

Could you check this?

kongyi added a comment.Nov 1 2019, 1:59 PM

@kongyi Hmm we have both x86_common/floatdixf.c and x86_64/floatdixf.c. I think both x86_64h_SOURCES and x86_64_SOURCES will end up with both x86_common/floatdixf.c and x86_64/floatdixf.c due to...

set(x86_64h_SOURCES ${x86_64h_SOURCES} ${x86_ARCH_SOURCES})
set(x86_64_SOURCES ${x86_64_SOURCES} ${x86_ARCH_SOURCES})

I don't think the filtering algorithm (removing generic builtin implementations in favour of architecture specific implementations) handles this case. Due to both sources being in sub directories they are considered to both be architecture specific implementations.
If I'm right it should mean that with this patch running ninja check-builtins should result in an error due to me relanding 23a33d450b9a426eae7094b16472f8a51fb5488a, i.e. when lit runs we should detect that there is more than one implementation of floatdixf.

Could you check this?

Ah, I didn't notice this... Let me rework the patch to fix this.