I am inclined to revert this change, in line with readability and the other targets. I commented above that I found the original structure clearer. Others said similarly in the changes for other targets. I was happy to bring XCore in line with other targets, but they have not gone for multiple operations on one line. So I would prefer to revert, but welcome comments.

Are you blocked in some way due to the mismatch?

This has changed test totals reported on the buildbot dashboard, so I would be interested in a comment on that.

XCore OK.

I see D123467 is the cross-target patch for this, and was accepted, so LGTM.

If D123656 gets consensus then this looks right to bring XCore in line with it. But personally I think the original structure is clearer: one operation per line, with the MVT and action right next to it. What is the motive for the change?

LGTM thanks

LGTM.

LGTM but I would prefer to hear from other reviewers who commented on object-emission before.

The code LGTM. When object-emission was reintroduced in D98508, there was some discussion on whether XCore ought to use this feature, or provide an integrated assembler instead. Sorry I don't know NVPTX: is NVPTX different because it generates assembly as its natural output, and binary does not make sense? Or could it have an integrated assembler at some point?

As the test is specifying targets, I think it needs to be in both X86 and XCore areas. Otherwise compilers not supporting those targets will attempt the test.

LGTM

XCore files LGTM. Nice improvement.

Remove "unit" from description as recommended in review.

Thanks @gkistanova . Yes, I will remove "unit" as suggested.

@ikudrin Thanks for the comment and the buildbot links. Yes, I won't check in till approved by buildbot maintainers.

The clang-xcore build status changed from "Unexpected test result output SKIPPED" in https://lab.llvm.org/staging/#/builders/145/builds/1340, to "X skipped unit tests" in https://lab.llvm.org/staging/#/builders/145/builds/1342. If that was when the patch was staged, it has worked on the display of results.

llvm/include/llvm/Target/TargetSelectionDAG.td defines SDTMemBarrier. This seems to have been introduced in 9b254eed32028 for ISD::MEMBARRIER, which was removed some time ago. I can't find a use of it and I can build without it. Could SDTMemBarrier be removed and would it belong in this patch?

XCore change LGTM. (Commenting on XCore only.)

Yes, I will look at this for the XCore target.

Currently the only memory operands that XCore inline asm supports are indirect (*m) and they have to be globals. It doesn’t handle locals as operands, or plain “m”. (It doesn’t handle FrameIndex.) So in that sense these tests are expected to fail. As an alternative to XFAIL, I’ve started looking at handling these other cases, or at least finding out what is difficult about them. I suspect there is some difficulty, otherwise the original developer would have done it, but I can’t say what it is yet.

I'm looking at extending XCore inline asm, or at least understanding why it's a problem to handle these cases, to provide more context for any XFAIL.

@echristo Thanks for the comment, Eric. I'm happy to do what is expected. Do you mean that it's a bug not to accept these cases, and we should fix it rather than XFAIL? So the build should not be green from XFAIL but only from a fix in this case?

In a quick test, I used else if (TI.getTypeWidth(TI.getWCharType()) == 8) but did you want to avoid that?

At the moment Clang defines __XS1B__ for XCore, but really that's one subtarget, I need to patch to define __xcore__ . It's an embedded processor, usually bare metal, so wouldn't have an OS character set. I just saw this change and thought I'd mention it's only 8 bits wide - I don't know what the best approach is. I'll discuss with others. Thanks for the quick reply.

The XCore target has 8-bit wchar_t (unsigned char). Should there be a test for width == 8 and set to "UTF-8", or at least not "UTF-16"?

Use XFAIL

Invite inline assembly code owner to review.

Tidy up.

Thank you for the reviews, I appreciate people taking time on something that is only for this target.

Invite debug info code owner to review.

As suggested, excluded xcore from DebugInfo/Generic rather than patching each file.

Tidy up.

Omit DebugInfo/Generic on XCore to avoid annotating 70 separate files.

Thanks, I see what you mean about churn and maintenance. The integrated assembler is planned. I will rework the patch.

DebugInfo/Generic can be handled by two lines in lit.local.cfg:

@MaskRay Thanks for the comment. I will look at that. But DebugInfo/Generic has 78 files requiring object-emission and 60 not requiring it - isn't it worth still running the 60? (I looked at some to see what they were doing: running llvm-as, llvm-dis, and checking assembly output.)

Invite reviewers around llvm-mc tool tests.

Invite reviewers around llvm-mc tool tests.

Invite reviewers around lit.cfg.py changes.

Add reviewer suggestions from CodeGen/Generic history.

Thanks, Galina.

Thanks @clayborg

• Incorporate isConfigurationSupported in isObjectEmissionSupported

@labath Thanks for the quick response. That looks like a good idea. I will try that.

Run clang-format

arc --update with all changes.

[XCore] Do not override LLVM_LIT_ARGS: use -j from the factory.

https://github.com/llvm/llvm-zorg/commit/f128ee547d9f4d1fc9480b9e95b6c119d9a08392

Revise as per review comments.

Created by mistake.

I think this patch can be cancelled, because the issue is already fixed in the main branch. But please say if I have missed something.

I've reproduced the failure. The test passes when I change -march=xcore to -mtriple=xcore-unknown-unknown, as in main branch commit https://github.com/llvm/llvm-project/commit/15ca54525d6c2927b2a51b871a9e343c7ce1c2ea. Does that commit solve this problem and unblock D91556 ? (I will continue to investigate to understand the reason for the register swap.)

The specified XCore backend code owner has moved on from XMOS and from working on XCore. I will have a look at this patch.

Many thanks for review and approval. Please could it be committed as I do not have commit access? (I will request.)

Added reviewer suggestions from git history. If someone familiar with updating the documentation could commit for me, I would be grateful, as I do not have commit access.

Run clang-format

Run clang-format

Alternatively, if all 1-byte-character strings are acceptable, should I remove the check that the first token is a string literal, and omit the failing test case on XCore?