[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

@jhibbits, thank you for merging. Will we have this in LLVM 9.0?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

Not sure whether I understood you, do not you already have the common switch by 
feature, named spe, in Features["spe"] line for that?


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

@ruiu, we have some hardware, which bootloader does not support PT_GNU_STACK 
segments, and would therefore benefit quite a bit from this option. As this 
does not really depend on NetBSD support, could you please merge this patch in 
time for 9.0? Thanks!


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

https://reviews.llvm.org/D56554



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D28462: clang-format: Add new style option AlignConsecutiveMacros

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

Could somebody commit it into 9.0? Quite a lot of people depend on this option 
including us. Since it got accepted I do not see a reason for this to get 
postponed any further. Thanks!


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

https://reviews.llvm.org/D28462



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

Right, ok. I have been testing this for quite some time now, including maths, 
and so far had no issues. Can this get merged into 9.0? I do not believe there 
are enough obstacles to postpone it any further. Thanks!


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

@nemanjai, sorry, under merging I meant committing into llvm upstream.




Comment at: lib/Basic/Targets/PPC.cpp:318
+  Features["spe"] = llvm::StringSwitch(CPU)
+.Case("e500", true)
+.Case("8548", true)

nemanjai wrote:
> The `e500v2` that you added doesn't support SPE?
I rechecked the docs, and there is no e500v2 option for -mcpu in GCC:
https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000-and-PowerPC-Options.

GCC defines 8540 (currently missing) and 8548, which I suppose we should 
support with default switches for SPE. As for other options, there also is 
-me500, which enables SPE, and -me500mc, which does not. I believe the need of 
these options is discussible.

The author of the patch may have his own thoughts behind, but I am not sure if 
e500, e500v1, or e500v2 should be used as mcpu switches at all. I am not 
against it if it makes things more convenient though.


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

This is a series of patches, which I believe should merged altogether. 
Currently the following patches are relevant:

- https://reviews.llvm.org/D49754
- https://reviews.llvm.org/D54409
- https://reviews.llvm.org/D54583
- https://reviews.llvm.org/D56703

The patches are intended to add PowerPC SPE support, and they do not seem to 
break things outside. Initially I wanted them to get merged into 8.x, but 
extensive local testing unveiled a number of issues, so the time was missed. I 
believe all the 4 patches are pretty much ready for merging, aside the 
following:

- approval from @jhibbits and @kthomsen, who do some testing as well
- https://reviews.llvm.org/D49754#1401168 is fixed or declared a separate 
issue, handled outside of the patchset

Depending on the above the decision should be taken. Meanwhile, a test should 
be added for `__NO_FPRS__` near `PPC32-SPE:#define __SPE__ 1 ` now that we 
define it.


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

@jhibbits, @kthomsen, it appears that current patchset has issues when handling 
&& on me. I have it applied over llvm 8.0.0 rc2, and the following code returns 
0 to me with -O2 and below:

  #include 
  
  #define FEQUAL(x,y) (((x) - (y)) < 0.01) // could put fabs if needed
  
  typedef struct {
float x;
float y;
  } float2;
  
  static bool __attribute__((noinline)) equals(float2* f40, float2* f41) {
  return FEQUAL(f40->x, f41->x) && FEQUAL(f40->y, f41->y);
  }
  
  int main() {
  float2 a = {0.721569, 0.1234};
  float2 b = {0.721569, 0.1234};
  
  printf("%d\n", equals(, ));
  }

Does it reproduce for you?

GCC output (working):

  # _Bool __fastcall equals(float2 *f40, float2 *f41)
  .globl equals
  equals:
lwz   r9, 0(r3)
lis   r10, -0x7FFF
lwz   r8, 0(r4)
addi  r10, r10, -0x7198 # 0x80008E68
evldd r10, 0(r10)
efssubr9, r9, r8
efdcfsr9, r9
efdcmplt  cr7, r9, r10
ble   cr7, loc_8048
lwz   r3, 4(r3)
lwz   r9, 4(r4)
efssubr3, r3, r9
efdcfsr3, r3
efdcmplt  cr7, r3, r10
mfcr  r3
extrwir3, r3, 1,29
clrlwir3, r3, 24
blr
  loc_8048:
lir3, 0
blr

LLVM output (not working):

  # _Bool __fastcall equals(float2 *f40, float2 *f41)
  .globl equals
  equals:
lwz   r6, 0(r3)
lwz   r7, 0(r4)
lir5, -0x6160
lis   r8, -0x7FFF
evlddxr5, r8, r5
efssubr6, r6, r7
efdcfsr6, r6
efdcmplt  cr0, r6, r5
bge   loc_82B0
lwz   r3, 4(r3)
lwz   r4, 4(r4)
efssubr3, r3, r4
efdcfsr3, r3
efdcmplt  cr0, r3, r5
b loc_82B4
  loc_82B0:
crclr gt
  loc_82B4:
lir3, 0
lir4, 1
bgt   loc_82C4
blr
  loc_82C4:
addi  r3, r4, 0
blr


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a subscriber: hfinkel.
vit9696 added a comment.

That's pretty good. Do you think it is possible to land it in 8.0 release? 
@hfinkel?

@jhibbits could you please include this change too: 
https://reviews.llvm.org/D49754#1364865? We would prefer to continue using 
Linux target to be able to use LLVM sanitizers.


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

Thanks for pointing it out. You could use hasFeature from there during 
construction:

  return SetCGInfo(
  new PPC32TargetCodeGenInfo(Types, CodeGenOpts.FloatABI == "soft" || 
getTarget().hasFeature("spe")));

It works for me, but probably a separate argument is best to be used (or at 
least the current one is to be renamed).


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

Right, I noticed the same thing yesterday. There is an override calling 
LowerVAARG for 64-bit integers, yet that is not a thing that does lowering for 
all the rest. I believe it is derived somewhere from td calling conventions. I 
will check it out later this evening and mail you if I find anything (vit9696 
at avp dot su).


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

@jhibbits it appears that va_list is not functional with SPE (va_arg returns 
garbage for double and stuff like printf is not functional). Is this expected 
or I miss a patch?


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

Justin, I am currently testing the latest patches, yet so far it looks very 
good. Thanks.
I rechecked GCC, and it seems that it forces 64-bit long double for SPE 
regardless of the target.
Could you please force that in LLVM as well? While imperfect, I currently 
changed the following part of code in clang/lib/Basic/Targets/PPC.cpp, and it 
seems to work for the needs:

  } else if (Feature == "+spe") {
HasSPE = true;
LongDoubleWidth = LongDoubleAlign = 64;
LongDoubleFormat = ::APFloat::IEEEdouble();
  }


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

You are right, had to modify it like this to get the crash with FreeBSD triple:

  void f1(long double v, void *a)
  {
  }
  
  void f2(void* v, __builtin_va_list arg)
  {
f1(__builtin_va_arg(arg, long double), 0);
  }


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

Actually I am not sure about Linux, since this is bare metal, and I just used 
what fited. However, it does not look like 128-bit or 64-bit long doubles are 
related.
I retried to compile the test case with powerpc-gnu-freebsd target (and even 
made a compile-time assertion to ensure that long double is now 64-bit), yet it 
still crashed in a similar way.
Might it be another LLVM 7 vs LLVM 8 difference? Does it crash for you with 
Linux target?


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

@jhibbits sorry for not answering earlier, I was occupied with NY holidays, and 
then had a lot of stuff on the road.

Trying to sync to your latest changes, I merged the updated 
https://reviews.llvm.org/D54583 in my local copy with your fixes to libcall 
expansion.
From what I understood (correct me if I am wrong) it should have fixed the 
__divdc3 case.
However, it still appears appears unresolved to me, with a segmentation fault 
instead of selection error.

I narrowed a potentially smaller example, which reproduces the issue. Does it 
reproduce for you locally?

  void f1(long double v)
  {
  }
  
  void f2(void* v, __builtin_va_list arg)
  {
f1(__builtin_va_arg(arg, long double));
  }



  $ clang -c sample.c -target powerpc-gnu-linux-eabi -ffreestanding -nostdlib 
-femulated-tls -mcpu=8548 -mspe
  Stack dump:
  0.Program arguments: clang-7 -cc1 -triple powerpc-gnu-linux-eabi 
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names 
-main-file-name sample.c -mrelocation-model static -mthread-model posix 
-mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases 
-ffreestanding -fuse-init-array -target-cpu ppc -target-feature +spe 
-mfloat-abi hard -dwarf-column-info -debugger-tuning=gdb -target-linker-version 
409.12 -coverage-notes-file Desktop/sample/sample.gcno -resource-dir 
/llvm/llvm-7.0.1-Darwin-x86_64/lib/clang/7.0.1 -internal-isystem 
/usr/local/include -internal-isystem 
/llvm/llvm-7.0.1-Darwin-x86_64/lib/clang/7.0.1/include 
-internal-externc-isystem /include -internal-externc-isystem /usr/include 
-fdebug-compilation-dir Desktop/sample -ferror-limit 19 -fmessage-length 265 
-femulated-tls -fno-signed-char -fobjc-runtime=gcc -fdiagnostics-show-option 
-fcolor-diagnostics -o sample.o -x c Desktop/sample/sample.c -faddrsig 
  1. parser at end of file
  2.Code generation
  3.Running pass 'Function Pass Manager' on module 
'Desktop/sample/sample.c'.
  4.Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on 
function '@f2'
  0  clang-7  0x0001099af90a 
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
  1  clang-7  0x0001099afcfa SignalHandler(int) + 200
  2  libsystem_platform.dylib 0x7fff52975f5a _sigtramp + 26
  3  libsystem_platform.dylib 0x7fe219f0eec0 _sigtramp + 3344535424
  4  clang-7  0x0001091093e1 
llvm::PPCTargetLowering::LowerCall(llvm::TargetLowering::CallLoweringInfo&, 
llvm::SmallVectorImpl&) const + 867
  5  clang-7  0x000109f55b7a 
llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&) 
const + 3856
  6  clang-7  0x000109f686fd 
llvm::SelectionDAGBuilder::lowerInvokable(llvm::TargetLowering::CallLoweringInfo&,
 llvm::BasicBlock const*) + 357
  7  clang-7  0x000109f5ad64 
llvm::SelectionDAGBuilder::LowerCallTo(llvm::ImmutableCallSite, llvm::SDValue, 
bool, llvm::BasicBlock const*) + 1178
  8  clang-7  0x000109f4e05a 
llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) + 1016
  9  clang-7  0x000109f474c0 
llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 114
  10 clang-7  0x000109fa76d3 
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator, false, true>, 
llvm::ilist_iterator, false, true>, bool&) + 177
  11 clang-7  0x000109fa6dde 
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 5532
  12 clang-7  0x000109fa50f4 
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1474
  13 clang-7  0x0001090e0bcc (anonymous 
namespace)::PPCDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 70
  14 clang-7  0x0001094d4785 
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 117
  15 clang-7  0x00010965c36b 
llvm::FPPassManager::runOnFunction(llvm::Function&) + 335
  16 clang-7  0x00010965c505 
llvm::FPPassManager::runOnModule(llvm::Module&) + 49
  17 clang-7  0x00010965c7e6 
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 558
  18 clang-7  0x000109ae2839 
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions 
const&, clang::CodeGenOptions const&, clang::TargetOptions const&, 
clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, 
clang::BackendAction, std::__1::unique_ptr >) + 12981
  19 clang-7  0x000109c48ea2 
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 864
  20 clang-7  0x00010a40bbbf clang::ParseAST(clang::Sema&, 
bool, bool) + 458
  21 clang-7  0x000109dcb7d7 
clang::FrontendAction::Execute() + 69
  22 clang-7  0x000109d9d9fc 
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 664
  23 

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

Ok, I found the fix for the first crash that landed in 8.0 trunk. It works fine 
for me if backported to 7.0.1:
https://reviews.llvm.org/D50461


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

In D49754#1321078 , @glaubitz wrote:

> I have applied this patch to the llvm-toolchain-7 package in Debian and did 
> not see any regressions on x86_64 or 32-Bit PowerPC. Additionally, I have 
> included the patches from https://reviews.llvm.org/D54409 and 
> https://reviews.llvm.org/D54583 saw no regressions on x86_64 and 32-bit 
> PowerPC.
>
> All three patches will be part of the next upload of the llvm-toolchain-7 
> package in Debian unstable which will be version 1:7.0.1~+rc2-9.


Might the first crash from https://reviews.llvm.org/D49754#1183753 reproduce 
for you or perhaps you have already bisected to trunk to figure out the 
changest that fixes it?


Repository:
  rC Clang

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

https://reviews.llvm.org/D49754



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

Thanks for the fix. I made a quick check of the mentioned patch, and it looks 
like it does solve the issue. However, besides the previous crash, which 
remains unfixed as of 7.0.1rc2, there is another instruction selection failure 
crash that may be caused by the change. I have not yet had a chance to properly 
research it, but here is an example if you feel interested: 
http://llvm.org/svn/llvm-project/compiler-rt/tags/RELEASE_701/rc2/lib/builtins/divdc3.c

  clang -O3 -std=c11  -target powerpc-gnu-linux-eabi -ffreestanding -nostdlib 
-g -mcpu=e500 -mspe -femulated-tls -c divdc3.c -o divdc3.o
  fatal error: error in backend: Cannot select: 0x7fcb8184c270: i64 = 
build_pair 0x7fcb8184c208, 0x7fcb8184c1a0, divdc3.c:24:22
0x7fcb8184c208: i32,ch,glue = CopyFromReg 0x7fcb8184c1a0:1, Register:i32 
$r4, 0x7fcb8184c1a0:2, divdc3.c:24:22
  0x7fcb81846678: i32 = Register $r4
  0x7fcb8184c1a0: i32,ch,glue = CopyFromReg 0x7fcb8184c138, Register:i32 
$r3, 0x7fcb8184c138:1, divdc3.c:24:22
0x7fcb818465a8: i32 = Register $r3
0x7fcb8184c138: ch,glue = callseq_end 0x7fcb8184c0d0, 
TargetConstant:i32<8>, TargetConstant:i32<0>, 0x7fcb8184c0d0:1, divdc3.c:24:22
  0x7fcb81846408: i32 = TargetConstant<8>
  0x7fcb81846470: i32 = TargetConstant<0>
  0x7fcb8184c0d0: ch,glue = PPCISD::CALL 0x7fcb8184c000, 
TargetExternalSymbol:i32'fmax' [TF=1], Register:i32 $r3, Register:i32 $r4, 
Register:i32 $r5, Register:i32 $r6, RegisterMask:Untyped, 0x7fcb8184c000:1, 
divdc3.c:24:22
0x7fcb8184c068: i32 = TargetExternalSymbol'fmax' [TF=1]
0x7fcb818465a8: i32 = Register $r3
0x7fcb81846678: i32 = Register $r4
0x7fcb81849f48: i32 = Register $r5
0x7fcb8184a768: i32 = Register $r6
0x7fcb818467b0: Untyped = RegisterMask
0x7fcb8184c000: ch,glue = CopyToReg 0x7fcb8184a220, Register:i32 
$r6, 0x7fcb81842200, 0x7fcb8184a220:1, divdc3.c:24:22
  0x7fcb8184a768: i32 = Register $r6
  0x7fcb81842200: i32 = truncate 0x7fcb8184c680, divdc3.c:24:22
0x7fcb8184c680: i64,ch = load<(load 8 from %stack.7)> 
0x7fcb8184c618, FrameIndex:i32<7>, undef:i32, divdc3.c:24:22
  0x7fcb81846c28: i32 = FrameIndex<7>
  0x7fcb81842818: i32 = undef
  0x7fcb8184a220: ch,glue = CopyToReg 0x7fcb81849c70, Register:i32 
$r5, 0x7fcb8184c5b0, 0x7fcb81849c70:1, divdc3.c:24:22
0x7fcb81849f48: i32 = Register $r5
0x7fcb8184c5b0: i32 = truncate 0x7fcb8184c2d8, divdc3.c:24:22
  0x7fcb8184c2d8: i64 = srl 0x7fcb8184c680, Constant:i32<32>, 
divdc3.c:24:22
0x7fcb8184c680: i64,ch = load<(load 8 from %stack.7)> 
0x7fcb8184c618, FrameIndex:i32<7>, undef:i32, divdc3.c:24:22
  
  
0x7fcb81846fd0: i32 = Constant<32>
0x7fcb81849c70: ch,glue = CopyToReg 0x7fcb81846540, 
Register:i32 $r4, 0x7fcb818469b8, 0x7fcb81846540:1, divdc3.c:24:22
  0x7fcb81846678: i32 = Register $r4
  0x7fcb818469b8: i32 = truncate 0x7fcb8184c750, divdc3.c:24:22
0x7fcb8184c750: i64,ch = load<(load 8 from %stack.8)> 
0x7fcb818462d0, FrameIndex:i32<8>, undef:i32, divdc3.c:24:22
  
  
  0x7fcb81846540: ch,glue = CopyToReg 0x7fcb818470a0, 
Register:i32 $r3, 0x7fcb8184c6e8, divdc3.c:24:22
0x7fcb818465a8: i32 = Register $r3
0x7fcb8184c6e8: i32 = truncate 0x7fcb818463a0, 
divdc3.c:24:22
  
0x7fcb8184c1a0: i32,ch,glue = CopyFromReg 0x7fcb8184c138, Register:i32 $r3, 
0x7fcb8184c138:1, divdc3.c:24:22
  0x7fcb818465a8: i32 = Register $r3
  0x7fcb8184c138: ch,glue = callseq_end 0x7fcb8184c0d0, 
TargetConstant:i32<8>, TargetConstant:i32<0>, 0x7fcb8184c0d0:1, divdc3.c:24:22
0x7fcb81846408: i32 = TargetConstant<8>
0x7fcb81846470: i32 = TargetConstant<0>
0x7fcb8184c0d0: ch,glue = PPCISD::CALL 0x7fcb8184c000, 
TargetExternalSymbol:i32'fmax' [TF=1], Register:i32 $r3, Register:i32 $r4, 
Register:i32 $r5, Register:i32 $r6, RegisterMask:Untyped, 0x7fcb8184c000:1, 
divdc3.c:24:22
  0x7fcb8184c068: i32 = TargetExternalSymbol'fmax' [TF=1]
  0x7fcb818465a8: i32 = Register $r3
  0x7fcb81846678: i32 = Register $r4
  0x7fcb81849f48: i32 = Register $r5
  0x7fcb8184a768: i32 = Register $r6
  0x7fcb818467b0: Untyped = RegisterMask
  0x7fcb8184c000: ch,glue = CopyToReg 0x7fcb8184a220, Register:i32 $r6, 
0x7fcb81842200, 0x7fcb8184a220:1, divdc3.c:24:22
0x7fcb8184a768: i32 = Register $r6
0x7fcb81842200: i32 = truncate 0x7fcb8184c680, divdc3.c:24:22
  0x7fcb8184c680: i64,ch = load<(load 8 from %stack.7)> 
0x7fcb8184c618, FrameIndex:i32<7>, undef:i32, divdc3.c:24:22
0x7fcb81846c28: i32 = FrameIndex<7>
0x7fcb81842818: i32 = undef
0x7fcb8184a220: 

[PATCH] D49754: Add -m(no-)spe, and e500 CPU definitions and support to clang

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

Hello,

Thank you for working this. I tried the change and have a couple of suggestions:

1. -mspe option in GCC works like -mspe=yes or -mspe=no. While it does make 
sense to have it the way you did (-mno-spe and -mspe) it would be nice to have 
at least have an alias for compiler compatibility.
2. One of the known CPU examples with SPE support is MPC8548 
(https://www.nxp.com/docs/en/reference-manual/MPC8548ERM.pdf), it will be nice 
to have it recognised in -mcpu argument as 8548 like in GCC.

Other than that, it appears that the implementation has several issues. Since 
this patch is partially unmerged yet, I did not use bugzilla but include the 
information below.

1. The following code makes the compiler to crash:

  struct a {
long double b() const;
  };
  class c {
struct C {
  C(long d) : e(d) {}
  long e;
  double f;
};
unsigned g;
C h[5];
unsigned i;
void k(C d) {
  long j(g);
  if (j)
h[i] = d;
}
c (const a &);
  };
  c ::fn(const a ) {
double l = d.b();
k(l);
  }



  $ clang-7 -cc1 -triple powerpc-gnu-linux-eabi -emit-obj -target-cpu ppc 
-target-feature +spe -O2  t.cpp
  t.cpp:23:1: warning: control reaches end of non-void function
  }
  ^
  Stack dump:
  0.Program arguments: clang-7 -cc1 -triple powerpc-gnu-linux-eabi 
-emit-obj -target-cpu ppc -target-feature +spe -O2 t.cpp 
  1. parser at end of file
  2.Code generation
  3.Running pass 'Function Pass Manager' on module 't.cpp'.
  4.Running pass 'PowerPC DAG->DAG Pattern Instruction Selection' on 
function '@_ZN1c2fnERK1a'
  0  clang-7  0x00010a6e722d 
llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 37
  1  clang-7  0x00010a6e760d SignalHandler(int) + 185
  2  libsystem_platform.dylib 0x7fff6a4baf5a _sigtramp + 26
  3  clang-7  0x00010ac4948a 
llvm::DenseMapBase, llvm::detail::DenseMapPair >, unsigned int, unsigned int, llvm::DenseMapInfo, 
llvm::detail::DenseMapPair >::find(unsigned int 
const&) + 18
  4  clang-7  0x00010ac3e23e 
llvm::DAGTypeLegalizer::ExpandIntRes_SIGN_EXTEND(llvm::SDNode*, llvm::SDValue&, 
llvm::SDValue&) + 514
  5  clang-7  0x00010ac3a670 
llvm::DAGTypeLegalizer::ExpandIntegerResult(llvm::SDNode*, unsigned int) + 1774
  6  clang-7  0x00010ac49793 llvm::DAGTypeLegalizer::run() 
+ 531
  7  clang-7  0x00010ac4c1cd 
llvm::SelectionDAG::LegalizeTypes() + 57
  8  clang-7  0x00010acde3da 
llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 468
  9  clang-7  0x00010acdd8a9 
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 5521
  10 clang-7  0x00010acdbbc9 
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1433
  11 clang-7  0x000109e18962 (anonymous 
namespace)::PPCDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 70
  12 clang-7  0x00010a20d353 
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 113
  13 clang-7  0x00010a393af4 
llvm::FPPassManager::runOnFunction(llvm::Function&) + 338
  14 clang-7  0x00010a393c89 
llvm::FPPassManager::runOnModule(llvm::Module&) + 49
  15 clang-7  0x00010a393f66 
llvm::legacy::PassManagerImpl::run(llvm::Module&) + 556
  16 clang-7  0x00010a81a77b 
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions 
const&, clang::CodeGenOptions const&, clang::TargetOptions const&, 
clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, 
clang::BackendAction, std::__1::unique_ptr >) + 13071
  17 clang-7  0x00010a97e61c 
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 888
  18 clang-7  0x00010b14479c clang::ParseAST(clang::Sema&, 
bool, bool) + 458
  19 clang-7  0x00010aaff2b9 
clang::FrontendAction::Execute() + 67
  20 clang-7  0x00010aad1ac0 
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 664
  21 clang-7  0x00010ab3352c 
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1267
  22 clang-7  0x000109c49f00 cc1_main(llvm::ArrayRef, char const*, void*) + 1138
  23 clang-7  0x000109c4923d main + 7612
  24 libdyld.dylib0x7fff6a1ac015 start + 1
  25 libdyld.dylib0x000b start + 2514829303
  Segmentation fault: 11



2. Several instructions seem to fail at variable allocation due to improper 
type. For example, the following code will overwrite the variables on stack and 
crash:

  int global_var1;
  
  void test_func2(void) { }
  
  void test_func(int a1, long long a2, void *a3, int *a4, int *a5) {
  int *ptr = _var1;
  
  if (ptr != 0) {
  

[PATCH] D44927: Enable msan unconditionally on Linux

[vit9696 via Phabricator via cfe-commits]

vit9696 added a comment.

Now that https://reviews.llvm.org/D44926 was merged upstream, may I request 
this to be merged as well?
As stated above it is pretty much pointless to have the check doubled, and 
after more than a week nobody thought of any issue.
Thanks :)


Repository:
  rC Clang

https://reviews.llvm.org/D44927



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D44927: Enable msan unconditionally on Linux

[vit9696 via Phabricator via cfe-commits]

vit9696 created this revision.
vit9696 added a reviewer: eugenis.
Herald added a subscriber: cfe-commits.

Memeory sanitizer compatibility are already done in 
MemorySanitizer::doInitialization. It verifies whether the necessary offsets 
exist and bails out if not. For this reason it is no good to duplicate two 
checks in two projects. This patch removes clang check and postpones msan 
compatibility validation till MemorySanitizer::doInitialization.

Another reason for this patch is to allow using msan with any CPU (given 
compatible runtime) and custom mapping provided via the arguments added by 
https://reviews.llvm.org/D44926.


Repository:
  rC Clang

https://reviews.llvm.org/D44927

Files:
  lib/Driver/ToolChains/Linux.cpp


Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -863,16 +863,15 @@
   Res |= SanitizerKind::Fuzzer;
   Res |= SanitizerKind::FuzzerNoLink;
   Res |= SanitizerKind::KernelAddress;
+  Res |= SanitizerKind::Memory;
   Res |= SanitizerKind::Vptr;
   Res |= SanitizerKind::SafeStack;
   if (IsX86_64 || IsMIPS64 || IsAArch64)
 Res |= SanitizerKind::DataFlow;
   if (IsX86_64 || IsMIPS64 || IsAArch64 || IsX86 || IsArmArch || IsPowerPC64)
 Res |= SanitizerKind::Leak;
   if (IsX86_64 || IsMIPS64 || IsAArch64 || IsPowerPC64)
 Res |= SanitizerKind::Thread;
-  if (IsX86_64 || IsMIPS64 || IsPowerPC64 || IsAArch64)
-Res |= SanitizerKind::Memory;
   if (IsX86_64 || IsMIPS64)
 Res |= SanitizerKind::Efficiency;
   if (IsX86 || IsX86_64)


Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -863,16 +863,15 @@
   Res |= SanitizerKind::Fuzzer;
   Res |= SanitizerKind::FuzzerNoLink;
   Res |= SanitizerKind::KernelAddress;
+  Res |= SanitizerKind::Memory;
   Res |= SanitizerKind::Vptr;
   Res |= SanitizerKind::SafeStack;
   if (IsX86_64 || IsMIPS64 || IsAArch64)
 Res |= SanitizerKind::DataFlow;
   if (IsX86_64 || IsMIPS64 || IsAArch64 || IsX86 || IsArmArch || IsPowerPC64)
 Res |= SanitizerKind::Leak;
   if (IsX86_64 || IsMIPS64 || IsAArch64 || IsPowerPC64)
 Res |= SanitizerKind::Thread;
-  if (IsX86_64 || IsMIPS64 || IsPowerPC64 || IsAArch64)
-Res |= SanitizerKind::Memory;
   if (IsX86_64 || IsMIPS64)
 Res |= SanitizerKind::Efficiency;
   if (IsX86 || IsX86_64)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits