[PATCH] D70718: [AIX] Replace ExternalSymbolSDNode with a MCSymbolSDNode for memcpy/memset/memmove
Hubert Tong via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Dec 16 21:04:08 PST 2019
hubert.reinterpretcast added inline comments.
================
Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:5353
+
+ if (ExternalSymbolSDNode *E = dyn_cast<ExternalSymbolSDNode>(Callee)) {
+ const char *SymName = E->getSymbol();
----------------
Xiangling_L wrote:
> hubert.reinterpretcast wrote:
> > If the two conditions are mutually exclusive, then this should be an `else if`. If this check is meant to operate on the new `Callee` assigned in the block above, then a comment really should be added.
> Thanks for mentioning that, but in LLVM coding standard: [[ https://llvm.org/docs/CodingStandards.html#don-t-use-else-after-a-return | Don’t use else after a return ]], so I didn't use `else if ` here.
Exactly how does that part of the coding standard apply here? This `if` is reachable after the previous `if` block has been entered. Again, the previous `if` block modifies `Callee`. Is this check meant to operate upon the modified `Callee`?
================
Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:5356
+ //TODO: Remove this when the support ExternalSymbolSDNode is complete.
+ if (strcmp(SymName, "memcpy") == 0 || strcmp(SymName, "memmove") == 0 ||
+ strcmp(SymName, "memset") == 0) {
----------------
Xiangling_L wrote:
> hubert.reinterpretcast wrote:
> > sfertile wrote:
> > > I think there will be a handful of other symbols we will need to white list for now as well (not needed in this patch, but sooner rather then later). I suggest we add a function that determines if the name an ExternalSDNode refers to is one we support by using a StringSwitch of the accepted names. When a name is not a supported/expected symbol then we can dump the SDNode as part of the debug tracing, and fatal error.
> > There are other libc extended operations that don't seem to come through as an ExternalSDNode by default, such as for `memcmp`. @sfertile, do you have an suggested approach for this?
> I am not sure if I understand what you said correctly, but I think for those SDNode which doesn't come through as an `ExternalSDNode` will fall into `GlobalAddressSDNode`, for which we already add "." as a prefix for function entry point in previous commit?
>
> If I am wrong, can you state your concern more clearly?
This has to do with mapping a call to `memcmp` to the entry point symbol named `.___memcmp`.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D70718/new/
https://reviews.llvm.org/D70718
More information about the llvm-commits
mailing list