[PATCH] D137058: [Driver] [Modules] Support -fmodule-output (1/2)

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

(pulling this out from an inline comment, because it's hard to quote/smaller than it needs to be for more complex discussions):

> Oh, thanks for finding this. It is pretty bad that I didn't image we can specify multiple input module units in one command line.
>
>> What if you specify multiple source files on the command line without -c? Without -o you get test1.pcm and test2.pcm, but with -o foo you get foo.pcm overwriting foo.pcm. Perhaps if the output file specified isn't a .o file, we should ignore the -o and use the input-filename based naming? I guess we could reject this situation outright, and require the user to run multiple separate compilations. Though keeping features composable is nice.
>
> Now the name of the module file will be the same with the input file no matter if we specified -o or not. With -o specified, the module files will be generated into the same directory with the output file. Without -o specified, the module files will be generated in the working directory. It'll still be problematic if the user specify two inputs with the same name in two different directory, the module file of the latter will overwrite the former one. But I guess we don't need to handle such cases?
>
>> For instance - how does this interact with Apple's multiarch support (eg: clang++ test.cppm -fmodule-output -arch i386 -arch x86_64 -target x86_64_apple_darwin) - from my testing, without specifying an output file, you get something semi-usable/not simply incorrect: test-i386.pcm and test-x86_64.pcm. But if you try to name the output file you get foo.pcm and then another foo.pcm that overwrites the previous one. I think this could be taken care of if the suffix handling code was delegated down towards the else block that starts with SmallString<128> Output(getDefaultImageName());
>
> In the new implementation, I image we'll generate test-i386.pcm and test-x86_64.pcm even if we specified -o with -fmodule-output. But the weird thing is that when I tried to reproduce your example, the compiler told me the other archs are ignored. I'm not sure if I set something wrong or I must do it in Apple machine.
>
> BTW, I am not sure if I misunderstand you, but the else block that starts with SmallString<128> Output(getDefaultImageName()); handles about IMAGE types, which looks irreverent to me.



>> how does this interact with Apple's multiarch support
>
> Good question. What does split dwarf do in this case? Are differently named outputs generated or is a multi-arch dwarf file produced (assuming they exist)?

Split DWARF isn't supported on Darwin/MacOS/whatever it's called - the MachO debug info distribution model looks more like, but isn't quite, Split DWARF already (it keeps the debug info in .o files, doesn't link them into the final executable - and you can make a separate debug info archive with `dsymutil`).

> Rejecting the command line if it specifies multiple -arch options with -fmodule-output= seems fair to me (unless/until support for multi-arch .pcm files is added).

Yeah, trying to see if

>> I'm not sure if I set something wrong or I must do it in Apple machine.
>
> I don't recall for sure, but I think Apple Clang is needed. We noticed differences between community Clang and Apple Clang while I was at Coverity, but I don't recall the details.

I don't think this needs Apple Clang, but it does need a Darwin triple. I was reproducing/examining the behavior with `clang++ test.cppm -fmodule-output -arch i386 -arch x86_64 -### -target x86_64-apple-darwin`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D137058/new/

https://reviews.llvm.org/D137058