[PATCH] D70401: [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu accepted this revision.
zixuan-wu added a comment.
This revision is now accepted and ready to land.

LGTM if nobody objects.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D70401: [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D156363: [Driver] -###: exit with code 1 if hasErrorOccurred

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added a subscriber: sunshaoce.

I am afraid there is also error at clang/test/Driver/as-options.s  when default 
triple is 'riscv32-unknown-elf'


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156363

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

[PATCH] D149017: [RISCV] Rewrite all found class-based subroutines to functions

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Is it going to commit?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D149017

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

[PATCH] D156363: [Driver] -###: exit with code 1 if hasErrorOccurred

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/Driver/debug-options.c:245
 //
 // RUN: %clang -### -c -gsplit-dwarf -g -gno-pubnames %s 2>&1 | FileCheck 
-check-prefix=NOPUB %s
 //

Here should add not or specify the target with x86 because it fails when only 
RV target is compiled.

```
clang: error: -gsplit-dwarf is unsupported with RISC-V linker relaxation 
(-mrelax)
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156363

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

[PATCH] D154588: [CSKY] Optimize implementation of intrinsic 'llvm.cttz.i32'

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/test/CodeGen/CSKY/intrinsic.ll:21
+entry:
+  %ntz = call i32 @llvm.cttz.i32(i32 %x, i1 1)
+  ret i32 %ntz

I think we can also test the condition that the second argument is zero.


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

https://reviews.llvm.org/D154588

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

[PATCH] D154588: [CSKY] Optimize implementation of intrinsic 'llvm.cttz.i32'

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/CodeGen/CSKY/csky-builtins.c:1
+// RUN: %clang_cc1 -triple csky -emit-llvm -o - %s | FileCheck %s
+

benshi001 wrote:
> This file is pure test, has nothing to do with `llvm.cttz`, just to avoid 
> another patch.
Don't make unrelated patch together in one single commit.



Comment at: clang/test/CodeGen/CSKY/csky-builtins.c:67
+  return __builtin_bswap64(x);
+}

Those are target-independent intrinsics/builtins. I think it's no more need to 
test for specific target such as csky again, unless it's different behavior or 
output.



Comment at: llvm/test/CodeGen/CSKY/intrinsic.ll:36
+define i16 @bswap16(i16 %x) {
+; CHECK-LABEL: bswap16:
+; CHECK:   # %bb.0: # %entry

Again. It's related to cttz?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154588

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

[PATCH] D70401: [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp:66
   return CSR_XLEN_F32_Interrupt_SaveList;
 return CSR_Interrupt_SaveList;
   }

Here also need adjust for rve.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D70401: [RISCV] CodeGen of RVE and ilp32e/lp64e ABIs

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVFrameLowering.cpp:908
 
 static const MCPhysReg CSRegs[] = { RISCV::X1,  /* ra */
   RISCV::X5, RISCV::X6, RISCV::X7,  /* t0-t2 */

Hi, @wangpc it's hidden bug that out of range registers are saved/restored in 
prologue/epilogue


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D153674: [dataflow] Disallow implicit copy of Environment, use fork() instead

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D153674#4461195 , @sammccall wrote:

> Sorry about the delay, and thanks for the `.i`.
>
> It took me a while to work out what was going on, but it looks like it's just 
> a bug where GCC forgets to automatic-move.
> Fixed in 2f7d30dee8262746c3e8ee1f6f25be8c1ace9990 
> 

Thanks a lot.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153674

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

[PATCH] D153674: [dataflow] Disallow implicit copy of Environment, use fork() instead

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D153674#4455357 , @sammccall wrote:

> Hi, sorry about that - are you able to provide a full log, or link to a
> failing bot?
> That error message doesn't show where in the LLVM code the error occurs.

It can pass with gcc 8.  And I can upload the .i file.F28060172: error.i 


> g++ error.i -std=c++17
> In file included from /usr/include/c++/7/memory:64:0,
>
>   from 
> /iothome/wuzx/workspace/llvm-comm/llvm/include/llvm/Support/Casting.h:20,
>   from /iothome/wuzx/workspace/llvm-comm/clang/include/clang/Basic/LLVM.h:21,
>   from 
> /iothome/wuzx/workspace/llvm-comm/clang/include/clang/Basic/DiagnosticIDs.h:17,
>   from 
> /iothome/wuzx/workspace/llvm-comm/clang/include/clang/Basic/IdentifierTable.h:18,
>   from /iothome/wuzx/workspace/llvm-comm/clang/include/clang/AST/Stmt.h:20,
>   from 
> /iothome/wuzx/workspace/llvm-comm/clang/include/clang/Analysis/FlowSensitive/Transfer.h:17,
>   from 
> /iothome/wuzx/workspace/llvm-comm/clang/lib/Analysis/FlowSensitive/Transfer.cpp:14:
>
> /usr/include/c++/7/bits/stl_construct.h: In instantiation of ‘void 
> std::_Construct(_T1*, _Args&& ...) [with _T1 = 
> std::optional
>  >; _Args = {const 
> std::optional
>  >&}]’:
> /usr/include/c++/7/bits/stl_uninitialized.h:83:18:   required from ‘static 
> _ForwardIterator 
> std::__uninitialized_copy<_TrivialValueTypes>::__uninit_copy(_InputIterator, 
> _InputIterator, _ForwardIterator) [with _InputIterator = 
> __gnu_cxx::__normal_iterator std::optional
>  >*, 
> std::vector
>  >, 
> std::allocator
>  > > > >; _ForwardIterator = 
> std::optional
>  >*; bool _TrivialValueTypes = false]’
> /usr/include/c++/7/bits/stl_uninitialized.h:134:15:   required from 
> ‘_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator, 
> _ForwardIterator) [with _InputIterator = __gnu_cxx::__normal_iterator std::optional
>  >*, 
> std::vector
>  >, 
> std::allocator
>  > > > >; _ForwardIterator = 
> std::optional
>  >*]’
> /usr/include/c++/7/bits/stl_uninitialized.h:289:37:   required from 
> ‘_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator, 
> _ForwardIterator, std::allocator<_Tp>&) [with _InputIterator = 
> __gnu_cxx::__normal_iterator std::optional
>  >*, 
> std::vector
>  >, 
> std::allocator
>  > > > >; _ForwardIterator = 
> std::optional
>  >*; _Tp = 
> std::optional
>  >]’
> /usr/include/c++/7/bits/stl_vector.h:331:31:   required from 
> ‘std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with _Tp 
> = 
> std::optional
>  >; _Alloc = 
> std::allocator
>  > >]’
> /iothome/wuzx/workspace/llvm-comm/llvm/include/llvm/Support/Error.h:520:5:   
> required from ‘llvm::Expected::Expected(OtherT&&, 
> std::enable_if_t >*) [with OtherT = 
> std::vector
>  >, 
> std::allocator
>  > > >&; T = 
> std::vector
>  >, 
> std::allocator
>  > > >; std::enable_if_t > = void]’
> /iothome/wuzx/workspace/llvm-comm/clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h:235:10:
>required from 
> ‘llvm::Expected  AnalysisT::Lattice> > > > clang::dataflow::runDataflowAnalysis(const 
> clang::dataflow::ControlFlowContext&, AnalysisT&, const 
> clang::dataflow::Environment&, std::function const clang::dataflow::DataflowAnalysisState&)>) 
> [with AnalysisT = clang::dataflow::NoopAnalysis; typename AnalysisT::Lattice 
> = clang::dataflow::NoopLattice]’
> /iothome/wuzx/workspace/llvm-comm/clang/lib/Analysis/FlowSensitive/Transfer.cpp:871:38:
>required from ‘void 
> clang::dataflow::{anonymous}::TransferVisitor::transferInlineCall(const E*, 
> const clang::FunctionDecl*) [with E = clang::CXXConstructExpr]’
> /iothome/wuzx/workspace/llvm-comm/clang/lib/Analysis/FlowSensitive/Transfer.cpp:625:42:
>required from here
> /usr/include/c++/7/bits/stl_construct.h:75:7: error: use of deleted function 
> ‘std::optional
>  >::optional(const 
> std::optional
>  >&)’
>
>   { ::new(static_cast(__p)) _T1(std::forward<_Args>(__args)...); }
> ^~
>
> In file included from 
> /iothome/wuzx/workspace/llvm-comm/llvm/include/llvm/Support/Alignment.h:26:0,
>
>   from 
> /iothome/wuzx/workspace/llvm-comm/llvm/include/llvm/Support/TrailingObjects.h:50,
>   from 
> /iothome/wuzx/workspace/llvm-comm/clang/include/clang/AST/DeclGroup.h:16,
>   from /iothome/wuzx/workspace/llvm-comm/clang/include/clang/AST/Stmt.h:16,
>   from 
> /iothome/wuzx/workspace/llvm-comm/clang/include/clang/Analysis/FlowSensitive/Transfer.h:17,
>   from 
> /iothome/wuzx/workspace/llvm-comm/clang/lib/Analysis/FlowSensitive/Transfer.cpp:14:
>
> /usr/include/c++/7/optional:453:11: note: 
> ‘std::optional
>  >::optional(const 
> std::optional
>  >&)’ is implicitly deleted because the default definition would be 
> ill-formed:
>
>   class optional
> ^~~~
>
> /usr/include/c++/7/optional:453:11: error: use of deleted function ‘constexpr 
> std::_Enable_copy_move 

[PATCH] D153674: [dataflow] Disallow implicit copy of Environment, use fork() instead

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Hi, there is a compiling error introduced recently as like following when files 
under clang/lib/Analysis/FlowSensitive/ are being compiled such as 
TypeErasedDataflowAnalysis.cpp and Transfer.cpp. Does anybody meet also?

>   from /usr/include/c++/7/functional:60,
>   from 
> /iothome/wuzx/workspace/master-csky/clang/unittests/Analysis/FlowSensitive/TestingSupport.h:16,
>   from 
> /iothome/wuzx/workspace/master-csky/clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp:9:
>
> /usr/include/c++/7/optional:453:11: note: 
> ‘std::optional
>  >::optional(const 
> std::optional
>  >&)’ is implicitly deleted because the default definition would be 
> ill-formed:
>
>   class optional
> ^~~~
>
> /usr/include/c++/7/optional:453:11: error: use of deleted function ‘constexpr 
> std::_Enable_copy_move _Tag>::_Enable_copy_move(const std::_Enable_copy_move true, _Tag>&) [with _Tag = 
> std::optional
>  >]’
> In file included from /usr/include/c++/7/optional:43:0,
>
>   from /usr/include/c++/7/bits/node_handle.h:39,
>   from /usr/include/c++/7/bits/hashtable.h:37,
>   from /usr/include/c++/7/unordered_map:47,
>   from /usr/include/c++/7/functional:60,
>   from 
> /iothome/wuzx/workspace/master-csky/clang/unittests/Analysis/FlowSensitive/TestingSupport.h:16,
>   from 
> /iothome/wuzx/workspace/master-csky/clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp:9:
>
> /usr/include/c++/7/bits/enable_special_members.h:157:15: note: declared here
>
>   constexpr _Enable_copy_move(_Enable_copy_move const&) noexcept  = delete;
> ^
>
> In file included from /usr/include/c++/7

The gcc version is gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153674

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

[PATCH] D151397: [3/3][RISCV][POC] Model vxrm in C intrinsics for RVV fixed-point instruction vaadd, vasub

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/include/clang/Basic/riscv_vector.td:1734
+  __RISCV_VXRM_RDN = 2,
+  __RISCV_VXRM_ROD = 3,
+};

I am wondering if we need a dynamic mode enum which representing using current 
vxrm value? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151397

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

[PATCH] D152570: [clang] Apply -fmacro-prefix-map to anonymous tags in template arguments

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Hi,




Comment at: clang/test/CodeGenCXX/macro-prefix-map-lambda.cpp:11
+  auto *s = lambdatest([](){});
+// CHECK: @"__PRETTY_FUNCTION__._Z10lambdatestIZ4mainE3$_0EDaOT_" = private 
unnamed_addr constant [{{[0-9]+}} x i8] c"auto lambdatest(f &&) [f = (lambda at 
./UNLIKELY_PATH/empty{{/|}}{{.*}}.cpp:[[#@LINE-1]]:24)]\00", align 1
+

Hi, it's weird that the align in CSKY target is not 1, instead it's 4. Anybody 
know the key point?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152570

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

[PATCH] D153111: [clang][Serialization][RISCV] Increase the number of reserved predefined type IDs

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

I also caught this issue.


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

https://reviews.llvm.org/D153111

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

[PATCH] D142388: [clang] Add builtin_nondeterministic_value

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/CodeGen/builtins-nondeterministic-value.c:26
+// CHECK-LABEL: entry
+// CHECK: [[A:%.*]] = alloca double, align 8
+// CHECK: store double [[X:%.*]], ptr [[A]], align 8

ManuelJBrito wrote:
> zixuan-wu wrote:
> > hi, @ManuelJBrito , because double is 4 alignment in CSKY target, could you 
> > please update this with capture match pattern which makes it more adaptable?
> Hi, I'll make a patch dropping the alignment since it's not relevant for what 
> we are testing here.
Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142388

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

[PATCH] D142388: [clang] Add builtin_nondeterministic_value

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/CodeGen/builtins-nondeterministic-value.c:26
+// CHECK-LABEL: entry
+// CHECK: [[A:%.*]] = alloca double, align 8
+// CHECK: store double [[X:%.*]], ptr [[A]], align 8

hi, @ManuelJBrito , because double is 4 alignment in CSKY target, could you 
please update this with capture match pattern which makes it more adaptable?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142388

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

[PATCH] D148206: [clang] Do not crash after suggesting typo correction to constexpr if condition

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/SemaCXX/invalid-if-constexpr.cpp:7
+}
+void a() { if constexpr (__adl_swap<>) {}} // expected-error{{use of 
undeclared identifier '__adl_swap'; did you mean '__sync_swap'?}} \
+   // expected-note {{'__sync_swap' 
declared here}}

Hi, why  `did you mean '__sync_swap'` is not reported in riscv target? So it's 
failed in check-all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148206

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

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu abandoned this revision.
zixuan-wu added a comment.
Herald added subscribers: jobnoorman, luke.

As this issue is solved at https://reviews.llvm.org/D148124, abandon this 
revision.


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

https://reviews.llvm.org/D129824

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

[PATCH] D148124: [RISCV][Driver] Allow the use of CPUs with a different XLEN than the triple.

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Thx. It has solved the issue D129824 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D148124

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

[PATCH] D141899: [IR][X86] Remove X86AMX type in LLVM IR instead of target extension

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D141899#4065375 , @nikic wrote:

> In D141899#4061237 , @zixuan-wu 
> wrote:
>
>> With considering 
>> https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility I 
>> think we need make consensus to choose one option from following 2 options.
>>
>> 1. Remove X86amx type in IR totally. (what I am doing now)
>> 2. Without removing X86amx type in IR, just upgrade the x86amx type to 
>> target extension and also upgrade bitcast llvm instruction to 
>> intrinsic(required). It also includes changing the testcase to target 
>> extension type.
>
> I believe the right option is:
>
> 3. Remove x86_amx type from the (in-memory) IR representation, but support an 
> auto-upgrade for bitcode only.
>
> We do need bitcode auto-upgrade support as a matter of policy, and we 
> shouldn't support both type representation at the same time, that would 
> defeat the point of the change.
>
> In D141899#4061174 , @LuoYuanke 
> wrote:
>
>> I think target extension type is nice, if it is introduced 2 years ago I 
>> would vote for it. However my concern is the compatibility issue as I 
>> explained. We need to be compatible to the IR that built by previous 
>> compiler, and be compatible to the 3rd party software that based on the 
>> x86_amx type. I can't predict more risks for now if we replace an LLVM IR 
>> type, but I believe there is big risk hidden.
>
> Due to bitcode auto-upgrade, compatibility with old IR is retained. As long 
> as we avoid some of the API changes here, the impact on downstream code 
> should be fairly minimal. (Though as already pointed out, downstream impact 
> generally doesn't figure into LLVM design decisions anyway.)

Deal. And because I am on busy for a long time and it is also better to let 
intel guy handle x86-related feature, I am happy with the patch being 
commandeered.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141899

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

[PATCH] D141899: [IR][X86] Remove X86AMX type in LLVM IR instead of target extension

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

With considering 
https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility I think 
we need make consensus to choose one option from following 2 options.

1. Remove X86amx type in IR totally. (what I am doing now)
2. Without removing X86amx type in IR, just upgrade the x86amx type to target 
extension and also upgrade bitcast llvm instruction to intrinsic(required). It 
also includes changing the testcase to target extension type.

BTW, need we make consensus about whether to do this purify patch anymore?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141899

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

[PATCH] D141899: [IR][X86] Remove X86AMX type in LLVM IR instead of target extension

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D141899#4058173 , @LuoYuanke wrote:

> @zixuan-wu, changing x86_amx would break our internal code. May I know the 
> motivation to change the type?

The background is at https://reviews.llvm.org/D135202. No more motivation, just 
to purify LLVM IR and demonstrate target extension. I think putting 
target-specific type into LLVM IR was thoughtless at that moment. Considering 
there was no better solution at that time such as target extension, it's a 
workable workaround. But it should not keep going anymore if there is better 
way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141899

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

[PATCH] D137838: [Support] Move TargetParsers to new component

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/include/llvm/Support/RISCVISAInfo.h:10
+/// \file
+/// This header is deprecated in favour of `llvm/Support/RISCVISAInfo.h`.
+///

I think there is a typo that should be 'in favour of 
`llvm/TargetParser/RISCVISAInfo.h` '


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137838

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

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Ping.. Do we still prefer to specify target triple explicitly to make a check?


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

https://reviews.llvm.org/D129824

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

[PATCH] D136239: [testcase] [OpenMP] Fix the testcase error of check-all when DCLANG_DEFAULT_OPENMP_RUNTIME is not libomp

[Zixuan Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG55c2137939d8: [testcase][OpenMP] Fix the testcase error of 
check-all when… (authored by zixuan-wu).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136239

Files:
  clang/test/Driver/fopenmp.c
  clang/test/Index/openmp-tile.c


Index: clang/test/Index/openmp-tile.c
===
--- clang/test/Index/openmp-tile.c
+++ clang/test/Index/openmp-tile.c
@@ -1,4 +1,4 @@
-// RUN: c-index-test -test-load-source local %s -fopenmp -fopenmp-version=51 | 
FileCheck %s
+// RUN: c-index-test -test-load-source local %s -fopenmp=libomp 
-fopenmp-version=51 | FileCheck %s
 
 void test() {
 #pragma omp tile sizes(5)
Index: clang/test/Driver/fopenmp.c
===
--- clang/test/Driver/fopenmp.c
+++ clang/test/Driver/fopenmp.c
@@ -140,7 +140,7 @@
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC: "-{{B?}}static" {{.*}} "-liomp5"
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC-NOT: "-Bdynamic"
 //
-// RUN: %clang -target x86_64-linux-gnu -fopenmp -fopenmp-enable-irbuilder -c 
%s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMPIRBUILDER
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libomp 
-fopenmp-enable-irbuilder -c %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-CC1-OPENMPIRBUILDER
 //
 // CHECK-CC1-OPENMPIRBUILDER: "-cc1"
 // CHECK-CC1-OPENMPIRBUILDER-SAME: "-fopenmp"


Index: clang/test/Index/openmp-tile.c
===
--- clang/test/Index/openmp-tile.c
+++ clang/test/Index/openmp-tile.c
@@ -1,4 +1,4 @@
-// RUN: c-index-test -test-load-source local %s -fopenmp -fopenmp-version=51 | FileCheck %s
+// RUN: c-index-test -test-load-source local %s -fopenmp=libomp -fopenmp-version=51 | FileCheck %s
 
 void test() {
 #pragma omp tile sizes(5)
Index: clang/test/Driver/fopenmp.c
===
--- clang/test/Driver/fopenmp.c
+++ clang/test/Driver/fopenmp.c
@@ -140,7 +140,7 @@
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC: "-{{B?}}static" {{.*}} "-liomp5"
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC-NOT: "-Bdynamic"
 //
-// RUN: %clang -target x86_64-linux-gnu -fopenmp -fopenmp-enable-irbuilder -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMPIRBUILDER
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libomp -fopenmp-enable-irbuilder -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMPIRBUILDER
 //
 // CHECK-CC1-OPENMPIRBUILDER: "-cc1"
 // CHECK-CC1-OPENMPIRBUILDER-SAME: "-fopenmp"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D136239: [testcase] [OpenMP] Fix the testcase error of check-all when DCLANG_DEFAULT_OPENMP_RUNTIME is not libomp

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: jdoerfert, MaskRay.
Herald added subscribers: StephenFan, arphaman, guansong, yaxunl.
Herald added a project: All.
zixuan-wu requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1.
Herald added a project: clang.

When DCLANG_DEFAULT_OPENMP_RUNTIME is set to libgomp, there is some check-all 
error. The expected CHECK result only displays when fopenmp=libomp is specified 
explicitly.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D136239

Files:
  clang/test/Driver/fopenmp.c
  clang/test/Index/openmp-tile.c


Index: clang/test/Index/openmp-tile.c
===
--- clang/test/Index/openmp-tile.c
+++ clang/test/Index/openmp-tile.c
@@ -1,4 +1,4 @@
-// RUN: c-index-test -test-load-source local %s -fopenmp -fopenmp-version=51 | 
FileCheck %s
+// RUN: c-index-test -test-load-source local %s -fopenmp=libomp 
-fopenmp-version=51 | FileCheck %s
 
 void test() {
 #pragma omp tile sizes(5)
Index: clang/test/Driver/fopenmp.c
===
--- clang/test/Driver/fopenmp.c
+++ clang/test/Driver/fopenmp.c
@@ -140,7 +140,7 @@
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC: "-{{B?}}static" {{.*}} "-liomp5"
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC-NOT: "-Bdynamic"
 //
-// RUN: %clang -target x86_64-linux-gnu -fopenmp -fopenmp-enable-irbuilder -c 
%s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMPIRBUILDER
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libomp 
-fopenmp-enable-irbuilder -c %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-CC1-OPENMPIRBUILDER
 //
 // CHECK-CC1-OPENMPIRBUILDER: "-cc1"
 // CHECK-CC1-OPENMPIRBUILDER-SAME: "-fopenmp"


Index: clang/test/Index/openmp-tile.c
===
--- clang/test/Index/openmp-tile.c
+++ clang/test/Index/openmp-tile.c
@@ -1,4 +1,4 @@
-// RUN: c-index-test -test-load-source local %s -fopenmp -fopenmp-version=51 | FileCheck %s
+// RUN: c-index-test -test-load-source local %s -fopenmp=libomp -fopenmp-version=51 | FileCheck %s
 
 void test() {
 #pragma omp tile sizes(5)
Index: clang/test/Driver/fopenmp.c
===
--- clang/test/Driver/fopenmp.c
+++ clang/test/Driver/fopenmp.c
@@ -140,7 +140,7 @@
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC: "-{{B?}}static" {{.*}} "-liomp5"
 // CHECK-LD-STATIC-IOMP5-NO-BDYNAMIC-NOT: "-Bdynamic"
 //
-// RUN: %clang -target x86_64-linux-gnu -fopenmp -fopenmp-enable-irbuilder -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMPIRBUILDER
+// RUN: %clang -target x86_64-linux-gnu -fopenmp=libomp -fopenmp-enable-irbuilder -c %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-CC1-OPENMPIRBUILDER
 //
 // CHECK-CC1-OPENMPIRBUILDER: "-cc1"
 // CHECK-CC1-OPENMPIRBUILDER-SAME: "-fopenmp"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVFrameLowering.cpp:411
 // implemented such that the stack will always be 16 byte aligned.
 unsigned LibCallFrameSize = alignTo((STI.getXLen() / 8) * LibCallRegs, 16);
 RVFI->setLibCallStackSize(LibCallFrameSize);

I think this 16 should be adjusted as above logic for rv32e


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D116735: [RISCV] Adjust RISCV data layout by using n32:64 in layout string

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D116735#3429850 , @craig.topper 
wrote:

> I'm seeing a regression on 401.bzip2 and possibly 471.astar. And I'm not 
> seeing large improvements on 471.omnetpp or 483.xalancbmk.

LGTM. But do you still get regression on spec? Or any improvements?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116735

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

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVRegisterInfo.cpp:106
+for (size_t Reg = RISCV::X16; Reg <= RISCV::X31; Reg++)
+  markSuperRegs(Reserved, Reg);
+

I am wondering whether we need construct another new RegisterClass for RV32E 
instead of GPR, for example eGPR, so that the num and other info such as 
weight, etc of RegisterClass can adjust. Then the reserved logic is not 
necessary.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D134454: [Driver][Distro] Fix ArchLinux sysroot detection

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

It's fine for CSKY to use config file. I only have 2 points.

1. I agree sysroot should be separated from GCC because sysroot is not 
dependent to GCC and there is even not gcc when we use llvm runtime. This rule 
should also apply to multilib logic. Sysroot can detect multilib path 
individually.
2. From user view, it's not easy to add sysroot or config file path manually, 
so it needs good way to enable this functionality.


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

https://reviews.llvm.org/D134454

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

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D121445#3824657 , @MaskRay wrote:

> mips computed sysroot from GCCInstallation very early in 2013 
> rG08450bd55ccdc4aee4f5f73cde97e25b3c4ce5b9 
>  and 
> Android followed up in 2018 (D45291 ), but I 
> am not sure this is the correct direction.
> They are to support very special distributions. Hard coding the file 
> hierarchy for every Linux distribution just does not scale.
> I raised my concern on https://reviews.llvm.org/D134454#3824630 as well.
>
> With https://reviews.llvm.org/D134337 (default configuration file) we should 
> move the logic to use a default configuration file instead.

It's fine for me to use config file. I only have 2 points.

1. I agree sysroot should be separated from GCC because sysroot is not 
dependent to GCC and there is even not gcc when we use llvm runtime. This rule 
should also apply to multilib logic. Sysroot can detect multilib path 
individually.
2. From user view,  it's not easy to add sysroot or config file path manually, 
so it needs good way to enable this functionality.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121445

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

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

AFAIK, --target is clang-specific and transparent for compiler user in RV side. 
-m is also undefined or less used by RV user. It just uses -march to specify 32 
or 64 mode and extensions.
Is the convention specified in RV Spec?


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

https://reviews.llvm.org/D129824

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

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu marked an inline comment as not done.
zixuan-wu added a comment.

ping...


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

https://reviews.llvm.org/D129824

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

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/Driver/riscv-arch.c:410
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mcpu=sifive-s21 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s

jrtc27 wrote:
> This one maybe makes sense to allow, though gets murky once you have cores 
> that support writable XLEN as then the same CPU exists for both RV32 and RV64 
> (like how you can ask for say haswell i386 and x86_64) so I'm not entirely 
> sure...
For now, if the name of sifive-s21 can't be both RV32 and RV64. It must 
distinguish the name in RISCVTargetParser.def.



Comment at: clang/test/Driver/riscv-arch.c:414
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mabi=lp64 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s

jrtc27 wrote:
> IMO this kind of thing should remain an error, you're asking for an ABI that 
> doesn't exist for the requested architecture
IMO, if -march is accepted to override riscv32 target triple, and march can get 
by `riscv::getRISCVArch` function with -mabi, then it should also accept. Or 
`riscv::getRISCVArch` should not get -march from -mabi.


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

https://reviews.llvm.org/D129824

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

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D129824#3706654 , @asb wrote:

> @zixuan-wu we discussed this a bit in the last community sync call 
> .
>  One aspect that makes this patch a little hard to review is the lack of a 
> clear patch description summarising the behaviour before the patch, the 
> behaviour after the patch, and the motivation for the change. I appreciate 
> that the time isn't very convenient in all timezones, but if you were able to 
> attend the next call (18th August, same time) to discuss, that might really 
> help agree a path forwards on this change.

I updated the description. I think it can be understood after see D54214 
.


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

https://reviews.llvm.org/D129824

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

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D129824#3699911 , @kito-cheng 
wrote:

> Just realized the problem is trying to fixed the default value of `-mabi=`, 
> currently `clang -target riscv32-elf -march=rv64gc 
> -mabi=lp64d`/`riscv32-elf-clang -march=rv64gc -mabi=lp64d` is work, and match 
> the behavior of GCC did, `riscv32-elf-gcc -march=rv64gc -mabi=lp64d`.
>
> And this patch is trying to make following two command work: `clang -target 
> riscv32-elf -march=rv64gc`/`riscv32-elf-clang -march=rv64gc`, specify 
> `-march` and `-target` but no `-mabi`.
>
> That is different story now, GCC isn't deduce the default abi from either 
> target triple or abi, so if you invoke gcc with `riscv32-elf-gcc 
> -march=rv64gc` or `riscv64-elf-gcc -march=rv32gc`, you will got error message 
> like that: `cc1: error: ABI requires '-march=rv32'` or `cc1: error: ABI 
> requires '-march=rv64'`.
>
> So that's not compatible issue with GCC, that's sort of clang driver specify 
> issue, and I don't have strong opinion on this.
>
> ---
>
> As a GNU toolchain developer, I would say, we are not intend to change the 
> behavior of default value of `-mabi` or `-march`, the consensus among RISC-V 
> GNU toolchain maintainer is user should explicitly specify the `-march` and 
> `-mabi` if you are not using default `-march` and `-mabi`.

This patch is not about default value of mabi. It just tries to deduce march 
when -march option is not provided explicitly. 
It fixes the conflict between target triple and march about 32-bit/64-bit 
(riscv32 or riscv64) issue as before. Before this patch, this conflict only can 
be solved by specifying -march option explicitly.


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

https://reviews.llvm.org/D129824

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

[PATCH] D63329: Allow static linking of libc++ on Linux, just like -static-libstdc++

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added a subscriber: MaskRay.
Herald added a project: All.

Is this going to continue?
And also if we use libunwind to handle EH, then it uses dladdr function which 
need link libdl.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D63329

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

[PATCH] D93138: Add initial support for multilibs in Baremetal toolchain.

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:177
   if (!getDriver().SysRoot.empty())
-return getDriver().SysRoot;
+return getDriver().SysRoot + SelectedMultilib.osSuffix();
 

abidh wrote:
> zixuan-wu wrote:
> > I think the multilib osSuffix added here will make every multilib contain 
> > include dir, and those include dirs are the same. For lib, there should be 
> > different multilib dir. 
> > 
> > So it's better to add osSuffix at construction function like following I 
> > think instead of be part of sysroot.
> > 
> > ```
> > if (!SysRoot.empty()) {
> > llvm::sys::path::append(SysRoot, "lib", SelectedMultilib.osSuffix());
> > getFilePaths().push_back(std::string(SysRoot));
> >   }
> > ```
> > 
> > @abidh 
> The multilib include directories are not necessarily the same.  In my 
> opinion, having a separate include and lib directory for every multilib is 
> much cleaner then having all multilib share an include directory and then you 
> put multilib specific directories inside that.
So you are going to copy times of same include headers? For now,  GCC on RISCV 
is just sharing one same include directory and having multiple multilib 
directory under lib of root.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93138

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

[PATCH] D93138: Add initial support for multilibs in Baremetal toolchain.

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.
Herald added subscribers: pcwang-thead, luke957, StephenFan, MaskRay, 
arichardson.
Herald added a project: All.



Comment at: clang/lib/Driver/ToolChains/BareMetal.cpp:177
   if (!getDriver().SysRoot.empty())
-return getDriver().SysRoot;
+return getDriver().SysRoot + SelectedMultilib.osSuffix();
 

I think the multilib osSuffix added here will make every multilib contain 
include dir, and those include dirs are the same. For lib, there should be 
different multilib dir. 

So it's better to add osSuffix at construction function like following I think 
instead of be part of sysroot.

```
if (!SysRoot.empty()) {
llvm::sys::path::append(SysRoot, "lib", SelectedMultilib.osSuffix());
getFilePaths().push_back(std::string(SysRoot));
  }
```

@abidh 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93138

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

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D129824#3670586 , @reames wrote:

> This was very briefly discussed at today's sync up call.  We were running 
> short on time, so we didn't get a chance to talk through it, but there did 
> seem to be a consensus that discussion on the interface implications was 
> needed.  This should hopefully be on the agenda when we talk again in two 
> weeks.

Okay. Anybody else please more comments here before next sync-up call if you 
have.


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

https://reviews.llvm.org/D129824

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

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 445690.
zixuan-wu added a comment.

Remove unnecessary include header.


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

https://reviews.llvm.org/D129824

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/riscv-abi.c
  clang/test/Driver/riscv-arch.c


Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -392,12 +392,29 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
 // RUN: %clang --target=riscv64-unknown-elf -march=rv32i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mcpu=sifive-e20 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mcpu=sifive-e20 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mabi=ilp32 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mabi=ilp32 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
 // RV32-TARGET: "-triple" "riscv32-unknown-unknown-elf"
 
+
 // RUN: %clang --target=riscv32-unknown-elf -march=rv64i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
 // RUN: %clang --target=riscv64-unknown-elf -march=rv64i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mcpu=sifive-s21 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mcpu=sifive-s21 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mabi=lp64 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mabi=lp64 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
 // RV64-TARGET: "-triple" "riscv64-unknown-unknown-elf"
 
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32ifzfh01p0 -### %s \
Index: clang/test/Driver/riscv-abi.c
===
--- clang/test/Driver/riscv-abi.c
+++ clang/test/Driver/riscv-abi.c
@@ -40,11 +40,6 @@
 
 // CHECK-ILP32D: "-target-abi" "ilp32d"
 
-// RUN: not %clang --target=riscv32-unknown-elf %s -o %t.o -mabi=lp64 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-RV32-LP64 %s
-
-// CHECK-RV32-LP64: error: unknown target ABI 'lp64'
-
 // RUN: %clang --target=riscv64-unknown-elf %s -### 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-LP64 %s
 // RUN: %clang --target=riscv64-unknown-elf %s -### -mabi=lp64 2>&1 \
@@ -77,8 +72,3 @@
 // RUN:   | FileCheck -check-prefix=CHECK-LP64D  %s
 
 // CHECK-LP64D: "-target-abi" "lp64d"
-
-// RUN: not %clang --target=riscv64-unknown-elf %s -o %t.o -mabi=ilp32 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-RV64-ILP32 %s
-
-// CHECK-RV64-ILP32: error: unknown target ABI 'ilp32'
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "clang/Driver/Driver.h"
+#include "ToolChains/Arch/RISCV.h"
 #include "ToolChains/AIX.h"
 #include "ToolChains/AMDGPU.h"
 #include "ToolChains/AMDGPUOpenMP.h"
@@ -650,13 +651,16 @@
   }
 
   // If target is RISC-V adjust the target triple according to
-  // provided architecture name
-  A = Args.getLastArg(options::OPT_march_EQ);
-  if (A && Target.isRISCV()) {
-StringRef ArchName = A->getValue();
-if (ArchName.startswith_insensitive("rv32"))
+  // provided architecture relative info such as -march/-mcpu/-mabi.
+  if (Target.isRISCV()) {
+StringRef ArchName = tools::riscv::getRISCVArch(Args, Target);
+llvm::Triple::ArchType RVArch = Target.getArch();
+
+if (RVArch == llvm::Triple::riscv64 &&
+ArchName.startswith_insensitive("rv32"))
   Target.setArch(llvm::Triple::riscv32);
-else if (ArchName.startswith_insensitive("rv64"))
+else if (RVArch == llvm::Triple::riscv32 &&
+ ArchName.startswith_insensitive("rv64"))
   Target.setArch(llvm::Triple::riscv64);
   }
 


Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -392,12 +392,29 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
 // RUN: %clang --target=riscv64-unknown-elf -march=rv32i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mcpu=sifive-e20 -### 

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:660
+
+if (RVArch == llvm::Triple::riscv64 &&
+ArchName.startswith_insensitive("rv32"))

eopXD wrote:
> Do we need to throw error (or warning) when these two (`RVArch` and 
> `ArchName`) don't match?
It just overrides it as before to not report error when for example default 
triple is rv64 with user passing -march=rv32xxx


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129824

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

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D129824#3653895 , @jrtc27 wrote:

> Does GCC allow this or not? Because this strikes me as a bad idea at first 
> sight…

GCC can deduce from -mcpu but not -mabi.

> riscv64-unknown-linux-gnu-gcc a.c -mabi=ilp32
> cc1: error: ABI requires '-march=rv32'

But I think it can be negotiated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129824

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

[PATCH] D54214: [RISCV] Set triple based on -march flag

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added subscribers: sunshaoce, pcwang-thead, eopXD, VincentWu, luke957, 
StephenFan, vkmr, frasercrmck, evandro, luismarques, MaskRay, arichardson.
Herald added a project: All.

In D54214#1737255 , @simoncook wrote:

> Rebase.
>
> @lenary Following the discussion regarding D69383 
> , I think it's best for now to keep the 
> logic just keeping `-march` directly, rather than using `getRISCVArch`. I 
> think in the case of `-target risc32-. -mabi=lp64` I think it would 
> confuse users if the tools suddenly changed to doing an rv64 compile. If we 
> disable that, all that function would provide me is the same StringRef I'm 
> already evaluating. I think adding any extra flag to indicate whether a 
> rv32<->rv64 switch is acceptable would just make the code unnecessarily more 
> messy. I think in the future if `getRISCVArch` evaluates more flags, then it 
> might make sense to reconsider this.

I think the case of `-target risc32-. -mabi=lp64` is acceptable since the 
-target is less usable than -march/-mabi/-mcpu and is almost invisible to users.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D54214

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

[PATCH] D129824: [RISCV] Set triple based on -march flag which can be deduced in more generic way

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: simoncook, lenary, asb.
Herald added subscribers: sunshaoce, VincentWu, luke957, StephenFan, vkmr, 
frasercrmck, evandro, luismarques, apazos, sameer.abuasal, s.egerton, Jim, 
benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, 
edward-jones, zzheng, jrtc27, shiva0217, kito-cheng, niosHD, sabuasal, 
johnrusso, rbar, arichardson.
Herald added a project: All.
zixuan-wu requested review of this revision.
Herald added subscribers: cfe-commits, pcwang-thead, eopXD, MaskRay.
Herald added a project: clang.

Now RISC-V the value provided to -march can determine whether to compile for 
32- or 64-bit RISC-V irrespective of the target provided to the Clang driver. 
Further, -march can be deduced in more generic way without providing -march but 
-mcpu or -mabi.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D129824

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/riscv-abi.c
  clang/test/Driver/riscv-arch.c


Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -392,12 +392,29 @@
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
 // RUN: %clang --target=riscv64-unknown-elf -march=rv32i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mcpu=sifive-e20 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mcpu=sifive-e20 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mabi=ilp32 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mabi=ilp32 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV32-TARGET %s
 // RV32-TARGET: "-triple" "riscv32-unknown-unknown-elf"
 
+
 // RUN: %clang --target=riscv32-unknown-elf -march=rv64i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
 // RUN: %clang --target=riscv64-unknown-elf -march=rv64i -### %s \
 // RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mcpu=sifive-s21 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mcpu=sifive-s21 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv32-unknown-elf -mabi=lp64 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
+// RUN: %clang --target=riscv64-unknown-elf -mabi=lp64 -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=RV64-TARGET %s
 // RV64-TARGET: "-triple" "riscv64-unknown-unknown-elf"
 
 // RUN: %clang --target=riscv32-unknown-elf -march=rv32ifzfh01p0 -### %s \
Index: clang/test/Driver/riscv-abi.c
===
--- clang/test/Driver/riscv-abi.c
+++ clang/test/Driver/riscv-abi.c
@@ -40,11 +40,6 @@
 
 // CHECK-ILP32D: "-target-abi" "ilp32d"
 
-// RUN: not %clang --target=riscv32-unknown-elf %s -o %t.o -mabi=lp64 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-RV32-LP64 %s
-
-// CHECK-RV32-LP64: error: unknown target ABI 'lp64'
-
 // RUN: %clang --target=riscv64-unknown-elf %s -### 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-LP64 %s
 // RUN: %clang --target=riscv64-unknown-elf %s -### -mabi=lp64 2>&1 \
@@ -77,8 +72,3 @@
 // RUN:   | FileCheck -check-prefix=CHECK-LP64D  %s
 
 // CHECK-LP64D: "-target-abi" "lp64d"
-
-// RUN: not %clang --target=riscv64-unknown-elf %s -o %t.o -mabi=ilp32 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-RV64-ILP32 %s
-
-// CHECK-RV64-ILP32: error: unknown target ABI 'ilp32'
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -7,6 +7,8 @@
 
//===--===//
 
 #include "clang/Driver/Driver.h"
+#include "ToolChains/Arch/RISCV.h"
+#include "ToolChains/AIX.h"
 #include "ToolChains/AIX.h"
 #include "ToolChains/AMDGPU.h"
 #include "ToolChains/AMDGPUOpenMP.h"
@@ -650,13 +652,16 @@
   }
 
   // If target is RISC-V adjust the target triple according to
-  // provided architecture name
-  A = Args.getLastArg(options::OPT_march_EQ);
-  if (A && Target.isRISCV()) {
-StringRef ArchName = A->getValue();
-if (ArchName.startswith_insensitive("rv32"))
+  // provided architecture relative info such as -march/-mcpu/-mabi.
+  if (Target.isRISCV()) {
+StringRef ArchName = tools::riscv::getRISCVArch(Args, Target);
+llvm::Triple::ArchType RVArch = Target.getArch();
+
+if (RVArch == llvm::Triple::riscv64 &&
+ArchName.startswith_insensitive("rv32"))
 

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG563cc3fda9a2: [Clang][CSKY] Add support about CSKYABIInfo 
(authored by zixuan-wu).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126451

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/CSKY/csky-abi.c
  clang/test/CodeGen/CSKY/csky-hard-abi.c
  clang/test/CodeGen/CSKY/csky-soft-abi.c

Index: clang/test/CodeGen/CSKY/csky-soft-abi.c
===
--- /dev/null
+++ clang/test/CodeGen/CSKY/csky-soft-abi.c
@@ -0,0 +1,395 @@
+// RUN: %clang_cc1 -no-opaque-pointers -triple csky -target-feature +fpuv2_sf -target-feature +fpuv2_df -target-feature +hard-float -emit-llvm %s -o - | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Doubles are passed in FPRs, so argument 'i' will be passed zero-extended
+// because it will be passed in a GPR.
+
+// CHECK: define{{.*}} void @f_fpr_tracking(double noundef %a, double noundef %b, double noundef %c, double noundef %d, i8 noundef zeroext %i)
+void f_fpr_tracking(double a, double b, double c, double d, uint8_t i) {}
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+struct double_s {
+  double f;
+};
+
+// CHECK: define{{.*}} void @f_double_s_arg(double %a.coerce)
+void f_double_s_arg(struct double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_double_s()
+struct double_s f_ret_double_s(void) {
+  return (struct double_s){1.0};
+}
+
+// A struct containing a double and any number of zero-width bitfields is
+// passed as though it were a standalone floating-point real.
+
+struct zbf_double_s {
+  int : 0;
+  double f;
+};
+struct zbf_double_zbf_s {
+  int : 0;
+  double f;
+  int : 0;
+};
+
+// CHECK: define{{.*}} void @f_zbf_double_s_arg(double %a.coerce)
+void f_zbf_double_s_arg(struct zbf_double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_s()
+struct zbf_double_s f_ret_zbf_double_s(void) {
+  return (struct zbf_double_s){1.0};
+}
+
+// CHECK: define{{.*}} void @f_zbf_double_zbf_s_arg(double %a.coerce)
+void f_zbf_double_zbf_s_arg(struct zbf_double_zbf_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_zbf_s()
+struct zbf_double_zbf_s f_ret_zbf_double_zbf_s(void) {
+  return (struct zbf_double_zbf_s){1.0};
+}
+
+// For argument type, the first 4*XLen parts of aggregate will be passed
+// in registers, and the rest will be passed in stack.
+// So we can coerce to integers directly and let backend handle it correctly.
+// For return type, aggregate which <= 2*XLen will be returned in registers.
+// Otherwise, aggregate will be returned indirectly.
+
+struct double_double_s {
+  double f;
+  double g;
+};
+struct double_float_s {
+  double f;
+  float g;
+};
+
+// CHECK: define{{.*}} void @f_double_double_s_arg([4 x i32] %a.coerce)
+void f_double_double_s_arg(struct double_double_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_double_s(%struct.double_double_s* noalias sret(%struct.double_double_s) align 4 %agg.result)
+struct double_double_s f_ret_double_double_s(void) {
+  return (struct double_double_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_float_s_arg([3 x i32] %a.coerce)
+void f_double_float_s_arg(struct double_float_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_float_s(%struct.double_float_s* noalias sret(%struct.double_float_s) align 4 %agg.result)
+struct double_float_s f_ret_double_float_s(void) {
+  return (struct double_float_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_double_s_arg_insufficient_fprs(float noundef %a, double noundef %b, double noundef %c, double noundef %d, double noundef %e, double noundef %f, double noundef %g, double noundef %i, [4 x i32] %h.coerce)
+void f_double_double_s_arg_insufficient_fprs(float a, double b, double c, double d,
+ double e, double f, double g, double i, struct double_double_s h) {}
+
+struct double_int8_s {
+  double f;
+  int8_t i;
+};
+struct double_uint8_s {
+  double f;
+  uint8_t i;
+};
+struct double_int32_s {
+  double f;
+  int32_t i;
+};
+struct double_int64_s {
+  double f;
+  int64_t i;
+};
+struct double_int64bf_s {
+  double f;
+  int64_t i : 32;
+};
+struct double_int8_zbf_s {
+  double f;
+  int8_t i;
+  int : 0;
+};
+
+// CHECK: define{{.*}}  @f_double_int8_s_arg([3 x i32] %a.coerce)
+void f_double_int8_s_arg(struct double_int8_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_int8_s(%struct.double_int8_s* noalias sret(%struct.double_int8_s) align 4 %agg.result)
+struct double_int8_s f_ret_double_int8_s(void) {
+  return (struct double_int8_s){1.0, 2};
+}
+
+// CHECK: define{{.*}} void @f_double_uint8_s_arg([3 x i32] %a.coerce)
+void 

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 432820.

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

https://reviews.llvm.org/D126451

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/CSKY/csky-abi.c
  clang/test/CodeGen/CSKY/csky-hard-abi.c
  clang/test/CodeGen/CSKY/csky-soft-abi.c

Index: clang/test/CodeGen/CSKY/csky-soft-abi.c
===
--- /dev/null
+++ clang/test/CodeGen/CSKY/csky-soft-abi.c
@@ -0,0 +1,395 @@
+// RUN: %clang_cc1 -no-opaque-pointers -triple csky -target-feature +fpuv2_sf -target-feature +fpuv2_df -target-feature +hard-float -emit-llvm %s -o - | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Doubles are passed in FPRs, so argument 'i' will be passed zero-extended
+// because it will be passed in a GPR.
+
+// CHECK: define{{.*}} void @f_fpr_tracking(double noundef %a, double noundef %b, double noundef %c, double noundef %d, i8 noundef zeroext %i)
+void f_fpr_tracking(double a, double b, double c, double d, uint8_t i) {}
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+struct double_s {
+  double f;
+};
+
+// CHECK: define{{.*}} void @f_double_s_arg(double %a.coerce)
+void f_double_s_arg(struct double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_double_s()
+struct double_s f_ret_double_s(void) {
+  return (struct double_s){1.0};
+}
+
+// A struct containing a double and any number of zero-width bitfields is
+// passed as though it were a standalone floating-point real.
+
+struct zbf_double_s {
+  int : 0;
+  double f;
+};
+struct zbf_double_zbf_s {
+  int : 0;
+  double f;
+  int : 0;
+};
+
+// CHECK: define{{.*}} void @f_zbf_double_s_arg(double %a.coerce)
+void f_zbf_double_s_arg(struct zbf_double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_s()
+struct zbf_double_s f_ret_zbf_double_s(void) {
+  return (struct zbf_double_s){1.0};
+}
+
+// CHECK: define{{.*}} void @f_zbf_double_zbf_s_arg(double %a.coerce)
+void f_zbf_double_zbf_s_arg(struct zbf_double_zbf_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_zbf_s()
+struct zbf_double_zbf_s f_ret_zbf_double_zbf_s(void) {
+  return (struct zbf_double_zbf_s){1.0};
+}
+
+// For argument type, the first 4*XLen parts of aggregate will be passed
+// in registers, and the rest will be passed in stack.
+// So we can coerce to integers directly and let backend handle it correctly.
+// For return type, aggregate which <= 2*XLen will be returned in registers.
+// Otherwise, aggregate will be returned indirectly.
+
+struct double_double_s {
+  double f;
+  double g;
+};
+struct double_float_s {
+  double f;
+  float g;
+};
+
+// CHECK: define{{.*}} void @f_double_double_s_arg([4 x i32] %a.coerce)
+void f_double_double_s_arg(struct double_double_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_double_s(%struct.double_double_s* noalias sret(%struct.double_double_s) align 4 %agg.result)
+struct double_double_s f_ret_double_double_s(void) {
+  return (struct double_double_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_float_s_arg([3 x i32] %a.coerce)
+void f_double_float_s_arg(struct double_float_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_float_s(%struct.double_float_s* noalias sret(%struct.double_float_s) align 4 %agg.result)
+struct double_float_s f_ret_double_float_s(void) {
+  return (struct double_float_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_double_s_arg_insufficient_fprs(float noundef %a, double noundef %b, double noundef %c, double noundef %d, double noundef %e, double noundef %f, double noundef %g, double noundef %i, [4 x i32] %h.coerce)
+void f_double_double_s_arg_insufficient_fprs(float a, double b, double c, double d,
+ double e, double f, double g, double i, struct double_double_s h) {}
+
+struct double_int8_s {
+  double f;
+  int8_t i;
+};
+struct double_uint8_s {
+  double f;
+  uint8_t i;
+};
+struct double_int32_s {
+  double f;
+  int32_t i;
+};
+struct double_int64_s {
+  double f;
+  int64_t i;
+};
+struct double_int64bf_s {
+  double f;
+  int64_t i : 32;
+};
+struct double_int8_zbf_s {
+  double f;
+  int8_t i;
+  int : 0;
+};
+
+// CHECK: define{{.*}}  @f_double_int8_s_arg([3 x i32] %a.coerce)
+void f_double_int8_s_arg(struct double_int8_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_int8_s(%struct.double_int8_s* noalias sret(%struct.double_int8_s) align 4 %agg.result)
+struct double_int8_s f_ret_double_int8_s(void) {
+  return (struct double_int8_s){1.0, 2};
+}
+
+// CHECK: define{{.*}} void @f_double_uint8_s_arg([3 x i32] %a.coerce)
+void f_double_uint8_s_arg(struct double_uint8_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_uint8_s(%struct.double_uint8_s* noalias sret(%struct.double_uint8_s) align 4 %agg.result)

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

BTW, I have run llvm-test-suite, it passed.


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

https://reviews.llvm.org/D126451

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

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:11708
+  case llvm::Triple::csky: {
+bool IsSoftFloat = !getTarget().hasFeature("hard-float-abi");
+bool hasFP64 = getTarget().hasFeature("fpuv2_df") ||

DavidSpickett wrote:
> I see a "hard-float" and "hard-float-abi" in this change. Is it safe to check 
> just for "hard-float-abi" here?
> 
> Just checking, I assume it's fine. You could have hardware with hard float 
> but you want to compile for soft float abi. This allows that.
> You could have hardware with hard float but you want to compile for soft 
> float abi. This allows that.

Yes. As you said.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:11710
+bool hasFP64 = getTarget().hasFeature("fpuv2_df") ||
+   getTarget().hasFeature("fpuv3_df");
+return SetCGInfo(new CSKYTargetCodeGenInfo(Types, IsSoftFloat ? 0

DavidSpickett wrote:
> Silly question, was/is there an fpuv1 and was it 32 bit only? (I assume so)
I think fpuv1 is not supported anymore in llvm.


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

https://reviews.llvm.org/D126451

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

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D126451#3539656 , @rengolin wrote:

> This looks good to me, but wait to make sure others see it, too.
>
> My reasons are: it is largely similar to RISCV implementation, it seems to 
> follow what I expected of the ABI (which is similar to other targets) and has 
> a large corpus of tests.
>
> I can't comment on the specifics of the ABI implementation (I haven't read 
> the ABI document *that* thoroughly), but as David said, issues will be picked 
> up by tests until the target reaches maturity.

I don't think it is largely similar to RISCV implementation except for the code 
structure and test reuse. And the test result is big different.


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

https://reviews.llvm.org/D126451

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

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D126451#3539512 , @DavidSpickett 
wrote:

> Can you reupload with more context? See 
> https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
>
> I doubt I'll be able to give any in depth review but if things look good 
> generally I'm sure you'll find the issues through your own testing as time 
> goes on.

Well, sorry that I forgot to add -U99 option.


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

https://reviews.llvm.org/D126451

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

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 432228.

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

https://reviews.llvm.org/D126451

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/CSKY/csky-abi.c
  clang/test/CodeGen/CSKY/csky-hard-abi.c

Index: clang/test/CodeGen/CSKY/csky-hard-abi.c
===
--- /dev/null
+++ clang/test/CodeGen/CSKY/csky-hard-abi.c
@@ -0,0 +1,394 @@
+// RUN: %clang_cc1 -no-opaque-pointers -triple csky -target-feature +fpuv2_sf -target-feature +fpuv2_df -target-feature +hard-float-abi -target-feature +hard-float -emit-llvm %s -o - | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Doubles are passed in FPRs, so argument 'i' will be passed zero-extended
+// because it will be passed in a GPR.
+
+// CHECK: define{{.*}} void @f_fpr_tracking(double noundef %a, double noundef %b, double noundef %c, double noundef %d, i8 noundef zeroext %i)
+void f_fpr_tracking(double a, double b, double c, double d, uint8_t i) {}
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+struct double_s {
+  double f;
+};
+
+// CHECK: define{{.*}} void @f_double_s_arg(double %a.coerce)
+void f_double_s_arg(struct double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_double_s()
+struct double_s f_ret_double_s(void) {
+  return (struct double_s){1.0};
+}
+
+// A struct containing a double and any number of zero-width bitfields is
+// passed as though it were a standalone floating-point real.
+
+struct zbf_double_s {
+  int : 0;
+  double f;
+};
+struct zbf_double_zbf_s {
+  int : 0;
+  double f;
+  int : 0;
+};
+
+// CHECK: define{{.*}} void @f_zbf_double_s_arg(double %a.coerce)
+void f_zbf_double_s_arg(struct zbf_double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_s()
+struct zbf_double_s f_ret_zbf_double_s(void) {
+  return (struct zbf_double_s){1.0};
+}
+
+// CHECK: define{{.*}} void @f_zbf_double_zbf_s_arg(double %a.coerce)
+void f_zbf_double_zbf_s_arg(struct zbf_double_zbf_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_zbf_s()
+struct zbf_double_zbf_s f_ret_zbf_double_zbf_s(void) {
+  return (struct zbf_double_zbf_s){1.0};
+}
+
+// For argument type, the first 4*XLen parts of aggregate will be passed
+// in registers, and the rest will be passed in stack.
+// So we can coerce to integers directly and let backend handle it correctly.
+// For return type, aggregate which <= 2*XLen will be returned in registers.
+// Otherwise, aggregate will be returned indirectly.
+
+struct double_double_s {
+  double f;
+  double g;
+};
+struct double_float_s {
+  double f;
+  float g;
+};
+
+// CHECK: define{{.*}} void @f_double_double_s_arg([4 x i32] %a.coerce)
+void f_double_double_s_arg(struct double_double_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_double_s(%struct.double_double_s* noalias sret(%struct.double_double_s) align 4 %agg.result)
+struct double_double_s f_ret_double_double_s(void) {
+  return (struct double_double_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_float_s_arg([3 x i32] %a.coerce)
+void f_double_float_s_arg(struct double_float_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_float_s(%struct.double_float_s* noalias sret(%struct.double_float_s) align 4 %agg.result)
+struct double_float_s f_ret_double_float_s(void) {
+  return (struct double_float_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_double_s_arg_insufficient_fprs(float noundef %a, double noundef %b, double noundef %c, double noundef %d, double noundef %e, double noundef %f, double noundef %g, double noundef %i, [4 x i32] %h.coerce)
+void f_double_double_s_arg_insufficient_fprs(float a, double b, double c, double d,
+ double e, double f, double g, double i, struct double_double_s h) {}
+
+struct double_int8_s {
+  double f;
+  int8_t i;
+};
+struct double_uint8_s {
+  double f;
+  uint8_t i;
+};
+struct double_int32_s {
+  double f;
+  int32_t i;
+};
+struct double_int64_s {
+  double f;
+  int64_t i;
+};
+struct double_int64bf_s {
+  double f;
+  int64_t i : 32;
+};
+struct double_int8_zbf_s {
+  double f;
+  int8_t i;
+  int : 0;
+};
+
+// CHECK: define{{.*}}  @f_double_int8_s_arg([3 x i32] %a.coerce)
+void f_double_int8_s_arg(struct double_int8_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_int8_s(%struct.double_int8_s* noalias sret(%struct.double_int8_s) align 4 %agg.result)
+struct double_int8_s f_ret_double_int8_s(void) {
+  return (struct double_int8_s){1.0, 2};
+}
+
+// CHECK: define{{.*}} void @f_double_uint8_s_arg([3 x i32] %a.coerce)
+void f_double_uint8_s_arg(struct double_uint8_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_uint8_s(%struct.double_uint8_s* noalias sret(%struct.double_uint8_s) align 4 %agg.result)
+struct 

[PATCH] D126451: [Clang][CSKY] Add support about CSKYABIInfo

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: rengolin, DavidSpickett.
Herald added a project: All.
zixuan-wu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

According to the CSKY ABIv2 document 
,
 construct the ABIInfo to handle argument passing and return of clang data 
type. It also includes how to emit and expand VAArg intrinsic.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D126451

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/CSKY/csky-abi.c
  clang/test/CodeGen/CSKY/csky-hard-abi.c

Index: clang/test/CodeGen/CSKY/csky-hard-abi.c
===
--- /dev/null
+++ clang/test/CodeGen/CSKY/csky-hard-abi.c
@@ -0,0 +1,394 @@
+// RUN: %clang_cc1 -no-opaque-pointers -triple csky -target-feature +fpuv2_sf -target-feature +fpuv2_df -target-feature +hard-float-abi -target-feature +hard-float -emit-llvm %s -o - | FileCheck %s
+
+#include 
+
+// Verify that the tracking of used GPRs and FPRs works correctly by checking
+// that small integers are sign/zero extended when passed in registers.
+
+// Doubles are passed in FPRs, so argument 'i' will be passed zero-extended
+// because it will be passed in a GPR.
+
+// CHECK: define{{.*}} void @f_fpr_tracking(double noundef %a, double noundef %b, double noundef %c, double noundef %d, i8 noundef zeroext %i)
+void f_fpr_tracking(double a, double b, double c, double d, uint8_t i) {}
+
+// A struct containing just one floating-point real is passed as though it
+// were a standalone floating-point real.
+struct double_s {
+  double f;
+};
+
+// CHECK: define{{.*}} void @f_double_s_arg(double %a.coerce)
+void f_double_s_arg(struct double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_double_s()
+struct double_s f_ret_double_s(void) {
+  return (struct double_s){1.0};
+}
+
+// A struct containing a double and any number of zero-width bitfields is
+// passed as though it were a standalone floating-point real.
+
+struct zbf_double_s {
+  int : 0;
+  double f;
+};
+struct zbf_double_zbf_s {
+  int : 0;
+  double f;
+  int : 0;
+};
+
+// CHECK: define{{.*}} void @f_zbf_double_s_arg(double %a.coerce)
+void f_zbf_double_s_arg(struct zbf_double_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_s()
+struct zbf_double_s f_ret_zbf_double_s(void) {
+  return (struct zbf_double_s){1.0};
+}
+
+// CHECK: define{{.*}} void @f_zbf_double_zbf_s_arg(double %a.coerce)
+void f_zbf_double_zbf_s_arg(struct zbf_double_zbf_s a) {}
+
+// CHECK: define{{.*}} double @f_ret_zbf_double_zbf_s()
+struct zbf_double_zbf_s f_ret_zbf_double_zbf_s(void) {
+  return (struct zbf_double_zbf_s){1.0};
+}
+
+// For argument type, the first 4*XLen parts of aggregate will be passed
+// in registers, and the rest will be passed in stack.
+// So we can coerce to integers directly and let backend handle it correctly.
+// For return type, aggregate which <= 2*XLen will be returned in registers.
+// Otherwise, aggregate will be returned indirectly.
+
+struct double_double_s {
+  double f;
+  double g;
+};
+struct double_float_s {
+  double f;
+  float g;
+};
+
+// CHECK: define{{.*}} void @f_double_double_s_arg([4 x i32] %a.coerce)
+void f_double_double_s_arg(struct double_double_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_double_s(%struct.double_double_s* noalias sret(%struct.double_double_s) align 4 %agg.result)
+struct double_double_s f_ret_double_double_s(void) {
+  return (struct double_double_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_float_s_arg([3 x i32] %a.coerce)
+void f_double_float_s_arg(struct double_float_s a) {}
+
+// CHECK: define{{.*}} void @f_ret_double_float_s(%struct.double_float_s* noalias sret(%struct.double_float_s) align 4 %agg.result)
+struct double_float_s f_ret_double_float_s(void) {
+  return (struct double_float_s){1.0, 2.0};
+}
+
+// CHECK: define{{.*}} void @f_double_double_s_arg_insufficient_fprs(float noundef %a, double noundef %b, double noundef %c, double noundef %d, double noundef %e, double noundef %f, double noundef %g, double noundef %i, [4 x i32] %h.coerce)
+void f_double_double_s_arg_insufficient_fprs(float a, double b, double c, double d,
+ double e, double f, double g, double i, struct double_double_s h) {}
+
+struct double_int8_s {
+  double f;
+  int8_t i;
+};
+struct double_uint8_s {
+  double f;
+  uint8_t i;
+};
+struct double_int32_s {
+  double f;
+  int32_t i;
+};
+struct double_int64_s {
+  double f;
+  int64_t i;
+};
+struct double_int64bf_s {
+  double f;
+  int64_t i : 32;
+};
+struct double_int8_zbf_s {
+  double f;
+  int8_t i;
+  int : 0;
+};
+
+// CHECK: define{{.*}}  @f_double_int8_s_arg([3 x i32] %a.coerce)
+void f_double_int8_s_arg(struct double_int8_s a) {}
+
+// CHECK: define{{.*}} void 

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGdca37af061fb: [NFC][Clang] Modify expect of fail test or 
XFAIL because CSKY align is different (authored by zixuan-wu).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124977

Files:
  clang/test/CodeGen/c-strings.c
  clang/test/Sema/builtin-alloca-with-align.c


Index: clang/test/Sema/builtin-alloca-with-align.c
===
--- clang/test/Sema/builtin-alloca-with-align.c
+++ clang/test/Sema/builtin-alloca-with-align.c
@@ -30,4 +30,8 @@
 
 void test8(void) {
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
__alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
__builtin_alloca_with_align is supposed to be in bits}}
+#if defined(__csky__)
+  // expected-error@-1 {{requested alignment must be 8 or greater}}
+  // Because the alignment of long long is 4 in CSKY target
+#endif
 }
Index: clang/test/CodeGen/c-strings.c
===
--- clang/test/CodeGen/c-strings.c
+++ clang/test/CodeGen/c-strings.c
@@ -20,6 +20,11 @@
 // fails the check for "@f3.x = ... align [ALIGN]", since ALIGN is derived
 // from the alignment of a single i8, which is still 1.
 
+// XFAIL: csky
+// CSKY aligns arrays of size 4+ bytes to a 32-bit boundary, which
+// fails the check for "@f2.x = ... align [ALIGN]", since ALIGN is derived
+// from the alignment of a single i8, which is still 1.
+
 #if defined(__s390x__)
 unsigned char align = 2;
 #else
@@ -69,4 +74,3 @@
 }
 
 char x[3] = "ola";
-


Index: clang/test/Sema/builtin-alloca-with-align.c
===
--- clang/test/Sema/builtin-alloca-with-align.c
+++ clang/test/Sema/builtin-alloca-with-align.c
@@ -30,4 +30,8 @@
 
 void test8(void) {
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), __alignof__(__INT64_TYPE__)); // expected-warning {{second argument to __builtin_alloca_with_align is supposed to be in bits}}
+#if defined(__csky__)
+  // expected-error@-1 {{requested alignment must be 8 or greater}}
+  // Because the alignment of long long is 4 in CSKY target
+#endif
 }
Index: clang/test/CodeGen/c-strings.c
===
--- clang/test/CodeGen/c-strings.c
+++ clang/test/CodeGen/c-strings.c
@@ -20,6 +20,11 @@
 // fails the check for "@f3.x = ... align [ALIGN]", since ALIGN is derived
 // from the alignment of a single i8, which is still 1.
 
+// XFAIL: csky
+// CSKY aligns arrays of size 4+ bytes to a 32-bit boundary, which
+// fails the check for "@f2.x = ... align [ALIGN]", since ALIGN is derived
+// from the alignment of a single i8, which is still 1.
+
 #if defined(__s390x__)
 unsigned char align = 2;
 #else
@@ -69,4 +74,3 @@
 }
 
 char x[3] = "ola";
-
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Gentle pin..


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

https://reviews.llvm.org/D124977

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

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 428585.
zixuan-wu added a comment.

Address comments.


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

https://reviews.llvm.org/D124977

Files:
  clang/test/CodeGen/c-strings.c
  clang/test/Sema/builtin-alloca-with-align.c


Index: clang/test/Sema/builtin-alloca-with-align.c
===
--- clang/test/Sema/builtin-alloca-with-align.c
+++ clang/test/Sema/builtin-alloca-with-align.c
@@ -30,4 +30,8 @@
 
 void test8(void) {
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
__alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
__builtin_alloca_with_align is supposed to be in bits}}
+#if defined(__csky__)
+  // expected-error@-1 {{requested alignment must be 8 or greater}}
+  // Because the alignment of long long is 4 in CSKY target
+#endif
 }
Index: clang/test/CodeGen/c-strings.c
===
--- clang/test/CodeGen/c-strings.c
+++ clang/test/CodeGen/c-strings.c
@@ -20,6 +20,11 @@
 // fails the check for "@f3.x = ... align [ALIGN]", since ALIGN is derived
 // from the alignment of a single i8, which is still 1.
 
+// XFAIL: csky
+// CSKY aligns arrays of size 4+ bytes to a 32-bit boundary, which
+// fails the check for "@f2.x = ... align [ALIGN]", since ALIGN is derived
+// from the alignment of a single i8, which is still 1.
+
 #if defined(__s390x__)
 unsigned char align = 2;
 #else
@@ -69,4 +74,3 @@
 }
 
 char x[3] = "ola";
-


Index: clang/test/Sema/builtin-alloca-with-align.c
===
--- clang/test/Sema/builtin-alloca-with-align.c
+++ clang/test/Sema/builtin-alloca-with-align.c
@@ -30,4 +30,8 @@
 
 void test8(void) {
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), __alignof__(__INT64_TYPE__)); // expected-warning {{second argument to __builtin_alloca_with_align is supposed to be in bits}}
+#if defined(__csky__)
+  // expected-error@-1 {{requested alignment must be 8 or greater}}
+  // Because the alignment of long long is 4 in CSKY target
+#endif
 }
Index: clang/test/CodeGen/c-strings.c
===
--- clang/test/CodeGen/c-strings.c
+++ clang/test/CodeGen/c-strings.c
@@ -20,6 +20,11 @@
 // fails the check for "@f3.x = ... align [ALIGN]", since ALIGN is derived
 // from the alignment of a single i8, which is still 1.
 
+// XFAIL: csky
+// CSKY aligns arrays of size 4+ bytes to a 32-bit boundary, which
+// fails the check for "@f2.x = ... align [ALIGN]", since ALIGN is derived
+// from the alignment of a single i8, which is still 1.
+
 #if defined(__s390x__)
 unsigned char align = 2;
 #else
@@ -69,4 +74,3 @@
 }
 
 char x[3] = "ola";
-
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/Sema/builtin-alloca-with-align.c:32
 void test8(void) {
+#if defined(__csky__)
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
__alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
__builtin_alloca_with_align is supposed to be in bits}}

aaron.ballman wrote:
> rengolin wrote:
> > zixuan-wu wrote:
> > > rengolin wrote:
> > > > This test is platform agnostic, perhaps the extra error could be in a 
> > > > new test, exclusively for csky?
> > > Then I prefer to split the file and add UNSUPPORTED for CSKY in the other 
> > > file which only contains test8
> > But then you wouldn't be testing the extra error you want... hmm.
> > 
> > Maybe it would be fine the way you did it originally.
> > 
> > Would be nice to get a clang person to give their opinion.
>   // Comment which explains why this is special.
> I think I would test this slightly differently:
> ```
> void test8(void) {
>   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
> __alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
> __builtin_alloca_with_align is supposed to be in bits}}
> #ifdef __csky__
>   // expected-error@-2 {{requested alignment must be 8 or greater}}
>   // Comment which explains why this is special.
> #endif // __csky__
> }
> ```
Reusing the first warning is good.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124977

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

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Could anybody else have a review or nominate a reviewer?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124977

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

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/Sema/builtin-alloca-with-align.c:32
 void test8(void) {
+#if defined(__csky__)
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
__alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
__builtin_alloca_with_align is supposed to be in bits}}

rengolin wrote:
> This test is platform agnostic, perhaps the extra error could be in a new 
> test, exclusively for csky?
Then I prefer to split the file and add UNSUPPORTED for CSKY in the other file 
which only contains test8


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D124977

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

[PATCH] D124977: [NFC][Clang] Modify expect of fail test or XFAIL because CSKY align is different

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: majnemer, kparzysz, ddunbar.
Herald added a project: All.
zixuan-wu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

CSKY is always in 4-byte align, no matter it's long long type. For aggregate 
type,  it's 4-byte align if its size is bigger than or equal to 4 bytes.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D124977

Files:
  clang/test/CodeGen/c-strings.c
  clang/test/Sema/builtin-alloca-with-align.c


Index: clang/test/Sema/builtin-alloca-with-align.c
===
--- clang/test/Sema/builtin-alloca-with-align.c
+++ clang/test/Sema/builtin-alloca-with-align.c
@@ -29,5 +29,10 @@
 }
 
 void test8(void) {
+#if defined(__csky__)
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
__alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
__builtin_alloca_with_align is supposed to be in bits}}
+   
 // expected-error@-1 {{requested alignment must be 8 or greater}}
+#else
+  __builtin_alloca_with_align(sizeof(__INT64_TYPE__), 
__alignof__(__INT64_TYPE__)); // expected-warning {{second argument to 
__builtin_alloca_with_align is supposed to be in bits}}
+#endif
 }
Index: clang/test/CodeGen/c-strings.c
===
--- clang/test/CodeGen/c-strings.c
+++ clang/test/CodeGen/c-strings.c
@@ -20,6 +20,11 @@
 // fails the check for "@f3.x = ... align [ALIGN]", since ALIGN is derived
 // from the alignment of a single i8, which is still 1.
 
+// XFAIL: csky
+// CSKY aligns arrays of size 4+ bytes to a 32-bit boundary, which
+// fails the check for "@f2.x = ... align [ALIGN]", since ALIGN is derived
+// from the alignment of a single i8, which is still 1.
+
 #if defined(__s390x__)
 unsigned char align = 2;
 #else
@@ -69,4 +74,3 @@
 }
 
 char x[3] = "ola";
-


Index: clang/test/Sema/builtin-alloca-with-align.c
===
--- clang/test/Sema/builtin-alloca-with-align.c
+++ clang/test/Sema/builtin-alloca-with-align.c
@@ -29,5 +29,10 @@
 }
 
 void test8(void) {
+#if defined(__csky__)
   __builtin_alloca_with_align(sizeof(__INT64_TYPE__), __alignof__(__INT64_TYPE__)); // expected-warning {{second argument to __builtin_alloca_with_align is supposed to be in bits}}
+// expected-error@-1 {{requested alignment must be 8 or greater}}
+#else
+  __builtin_alloca_with_align(sizeof(__INT64_TYPE__), __alignof__(__INT64_TYPE__)); // expected-warning {{second argument to __builtin_alloca_with_align is supposed to be in bits}}
+#endif
 }
Index: clang/test/CodeGen/c-strings.c
===
--- clang/test/CodeGen/c-strings.c
+++ clang/test/CodeGen/c-strings.c
@@ -20,6 +20,11 @@
 // fails the check for "@f3.x = ... align [ALIGN]", since ALIGN is derived
 // from the alignment of a single i8, which is still 1.
 
+// XFAIL: csky
+// CSKY aligns arrays of size 4+ bytes to a 32-bit boundary, which
+// fails the check for "@f2.x = ... align [ALIGN]", since ALIGN is derived
+// from the alignment of a single i8, which is still 1.
+
 #if defined(__s390x__)
 unsigned char align = 2;
 #else
@@ -69,4 +74,3 @@
 }
 
 char x[3] = "ola";
-
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D121445#3431569 , @dyung wrote:

> Hi, one of the tests you added. csky-toolchain.c seems to be failing on a 
> Windows build bot, and from a quick look, it appears to be a path separator 
> issue. Can you take a look?
>
> https://lab.llvm.org/buildbot/#/builders/216/builds/2452

Reference to other target toolchain case, it should add unsupported directive. 
Fixed it at https://reviews.llvm.org/rG9906d38252d112894f304ba1b4fbdcd2cc93ab19


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121445

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

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG97e496054a37: [Clang][CSKY] Add the CSKY target and compiler 
driver (authored by zixuan-wu).

Changed prior to commit:
  https://reviews.llvm.org/D121445?vs=419076=420697#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121445

Files:
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/CSKY.cpp
  clang/lib/Basic/Targets/CSKY.h
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.h
  clang/lib/Driver/ToolChains/CSKYToolChain.cpp
  clang/lib/Driver/ToolChains/CSKYToolChain.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/bin/ld
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtn.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtn.o
  clang/test/Driver/csky-arch-error.c
  clang/test/Driver/csky-arch.c
  clang/test/Driver/csky-cpus-error.c
  clang/test/Driver/csky-cpus.c
  clang/test/Driver/csky-toolchain.c
  clang/test/Preprocessor/csky-target-features.c
  clang/test/Preprocessor/init-csky.c
  llvm/lib/Support/CSKYTargetParser.cpp
  llvm/unittests/Support/CSKYTargetParserTest.cpp

Index: llvm/unittests/Support/CSKYTargetParserTest.cpp
===
--- llvm/unittests/Support/CSKYTargetParserTest.cpp
+++ llvm/unittests/Support/CSKYTargetParserTest.cpp
@@ -1061,18 +1061,11 @@
   EXPECT_FALSE(CSKY::getExtensionFeatures(CSKY::AEK_INVALID, Features));
 
   for (auto  : Extensions) {
-// test +extension
-Features.clear();
 CSKY::getExtensionFeatures(E.first, Features);
 EXPECT_TRUE(llvm::is_contained(Features, E.second.at(0)));
-EXPECT_EQ(Extensions.size(), Features.size());
-
-// test -extension
-Features.clear();
-CSKY::getExtensionFeatures(~E.first, Features);
-EXPECT_TRUE(llvm::is_contained(Features, E.second.at(1)));
-EXPECT_EQ(Extensions.size(), Features.size());
   }
+
+  EXPECT_EQ(Extensions.size(), Features.size());
 }
 
 TEST(TargetParserTest, CSKYFPUFeatures) {
Index: llvm/lib/Support/CSKYTargetParser.cpp
===
--- llvm/lib/Support/CSKYTargetParser.cpp
+++ llvm/lib/Support/CSKYTargetParser.cpp
@@ -172,8 +172,6 @@
   for (const auto  : CSKYARCHExtNames) {
 if ((Extensions & AE.ID) == AE.ID && AE.Feature)
   Features.push_back(AE.Feature);
-else if (AE.NegFeature)
-  Features.push_back(AE.NegFeature);
   }
 
   return true;
Index: clang/test/Preprocessor/init-csky.c
===
--- /dev/null
+++ clang/test/Preprocessor/init-csky.c
@@ -0,0 +1,211 @@
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=CSKY %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky-unknown-linux < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefixes=CSKY,CSKY-LINUX %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky \
+// RUN: -fforce-enable-int128 < /dev/null | FileCheck -match-full-lines \
+// RUN: -check-prefixes=CSKY,CSKY-INT128 %s
+// CSKY: #define _ILP32 1
+// CSKY: #define __ATOMIC_ACQUIRE 2
+// CSKY: #define __ATOMIC_ACQ_REL 4
+// CSKY: #define __ATOMIC_CONSUME 1
+// CSKY: #define __ATOMIC_RELAXED 0
+// CSKY: #define __ATOMIC_RELEASE 3
+// CSKY: #define __ATOMIC_SEQ_CST 5
+// CSKY: #define __BIGGEST_ALIGNMENT__ 4
+// CSKY: #define __BYTE_ORDER__ 

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D121445#3416518 , @rengolin wrote:

> There is also a test error:
>
>    TEST 'Clang :: Driver/csky-toolchain.c' FAILED 
> 
>   ...
>   /home/rengolin/devel/llvm-project/clang/test/Driver/csky-toolchain.c:16:24: 
> error: C-CSKY-LINUX-MULTI: expected string not found in input
>   // C-CSKY-LINUX-MULTI: 
> "{{.*}}/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/../../..{{/|}}..{{/|}}csky-linux-gnuabiv2/bin{{/|}}ld"
>   
>  ^
>
> I'm guessing this is the path of a local sysroot you have on your machine?
>
> If possible, try to get a new environment (container, VM, alternative 
> machine) and make sure a clean build still passes the tests.

I have met this before because the downloading of patch will ignore empty 
files. You can have a check that your apply does not contain new empty files in 
multilib_csky_linux_sdk.


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

https://reviews.llvm.org/D121445

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

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 419076.
zixuan-wu added a comment.
Herald added subscribers: StephenFan, dexonsmith, MaskRay.

Address comments.


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

https://reviews.llvm.org/D121445

Files:
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/CSKY.cpp
  clang/lib/Basic/Targets/CSKY.h
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.h
  clang/lib/Driver/ToolChains/CSKYToolChain.cpp
  clang/lib/Driver/ToolChains/CSKYToolChain.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/bin/ld
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtn.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtn.o
  clang/test/Driver/csky-arch-error.c
  clang/test/Driver/csky-arch.c
  clang/test/Driver/csky-cpus-error.c
  clang/test/Driver/csky-cpus.c
  clang/test/Driver/csky-toolchain.c
  clang/test/Preprocessor/csky-target-features.c
  clang/test/Preprocessor/init-csky.c
  llvm/lib/Support/CSKYTargetParser.cpp
  llvm/unittests/Support/CSKYTargetParserTest.cpp

Index: llvm/unittests/Support/CSKYTargetParserTest.cpp
===
--- llvm/unittests/Support/CSKYTargetParserTest.cpp
+++ llvm/unittests/Support/CSKYTargetParserTest.cpp
@@ -1061,18 +1061,11 @@
   EXPECT_FALSE(CSKY::getExtensionFeatures(CSKY::AEK_INVALID, Features));
 
   for (auto  : Extensions) {
-// test +extension
-Features.clear();
 CSKY::getExtensionFeatures(E.first, Features);
 EXPECT_TRUE(llvm::is_contained(Features, E.second.at(0)));
-EXPECT_EQ(Extensions.size(), Features.size());
-
-// test -extension
-Features.clear();
-CSKY::getExtensionFeatures(~E.first, Features);
-EXPECT_TRUE(llvm::is_contained(Features, E.second.at(1)));
-EXPECT_EQ(Extensions.size(), Features.size());
   }
+
+  EXPECT_EQ(Extensions.size(), Features.size());
 }
 
 TEST(TargetParserTest, CSKYFPUFeatures) {
Index: llvm/lib/Support/CSKYTargetParser.cpp
===
--- llvm/lib/Support/CSKYTargetParser.cpp
+++ llvm/lib/Support/CSKYTargetParser.cpp
@@ -172,8 +172,6 @@
   for (const auto  : CSKYARCHExtNames) {
 if ((Extensions & AE.ID) == AE.ID && AE.Feature)
   Features.push_back(AE.Feature);
-else if (AE.NegFeature)
-  Features.push_back(AE.NegFeature);
   }
 
   return true;
Index: clang/test/Preprocessor/init-csky.c
===
--- /dev/null
+++ clang/test/Preprocessor/init-csky.c
@@ -0,0 +1,211 @@
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=CSKY %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky-unknown-linux < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefixes=CSKY,CSKY-LINUX %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky \
+// RUN: -fforce-enable-int128 < /dev/null | FileCheck -match-full-lines \
+// RUN: -check-prefixes=CSKY,CSKY-INT128 %s
+// CSKY: #define _ILP32 1
+// CSKY: #define __ATOMIC_ACQUIRE 2
+// CSKY: #define __ATOMIC_ACQ_REL 4
+// CSKY: #define __ATOMIC_CONSUME 1
+// CSKY: #define __ATOMIC_RELAXED 0
+// CSKY: #define __ATOMIC_RELEASE 3
+// CSKY: #define __ATOMIC_SEQ_CST 5
+// CSKY: #define __BIGGEST_ALIGNMENT__ 4
+// CSKY: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// CSKY: #define __CHAR16_TYPE__ unsigned short
+// CSKY: #define __CHAR32_TYPE__ unsigned int
+// CSKY: #define __CHAR_BIT__ 8
+// CSKY: #define __DBL_DECIMAL_DIG__ 17
+// CSKY: #define 

[PATCH] D122089: [CUDA] Add getTargetFeatures for the NVPTX toolchain

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/Driver/ToolChains/Cuda.cpp:648
+#define CASE_CUDA_VERSION(CUDA_VER, PTX_VER)   
\
+  case CudaVersion::CUDA_##CUDA_VER:   
\
+PtxFeature = "+ptx" #PTX_VER;  
\

jhuber6 wrote:
> zixuan-wu wrote:
> > It's same name as `CudaVersion` variable above, and it cause compile error. 
> > @jhuber6 
> > Maybe the error depends on host compiler version so that it does not report 
> > immediately.
> Fixed in rGd91223274145. Thanks for pointing that out, it worked fined 
> locally.
Thank you for your quick action.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122089

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

[PATCH] D122089: [CUDA] Add getTargetFeatures for the NVPTX toolchain

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/Driver/ToolChains/Cuda.cpp:648
+#define CASE_CUDA_VERSION(CUDA_VER, PTX_VER)   
\
+  case CudaVersion::CUDA_##CUDA_VER:   
\
+PtxFeature = "+ptx" #PTX_VER;  
\

It's same name as `CudaVersion` variable above, and it cause compile error. 
@jhuber6 
Maybe the error depends on host compiler version so that it does not report 
immediately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122089

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

[PATCH] D122160: [clang][extract-api] Refactor ExtractAPI and improve docs

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp:159
+  switch (Language) {
+  case Language::C:
+return "c";

It's same name as `Language` variable above, and it cause compile error. @zixuw 
Maybe the error depends on host compiler version so that it does not report 
immediately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122160

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

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D121445#3388842 , @rengolin wrote:

> I'm surprised these tests are passing for you. Perhaps you're not building or 
> running them all.
>
> To make sure you're running your tests, you need to build both clang and llvm 
> (`-DLLVM_ENABLE_PROJECTS=clang`) and run ninja/make `check-all`.
>
> You can also run `lit` directly on each test, but I can't remember how to do 
> that now...

I have enabled clang project building and run check-all test. Like ` 
-DLLVM_ENABLE_ASSERTIONS=On -DLLVM_ENABLE_PROJECTS="clang;llvm" 
-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="CSKY"`. So I am also surprised why those 
cases passed.


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

https://reviews.llvm.org/D121445

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

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

I have updated the patch. Any more comments?


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

https://reviews.llvm.org/D121445

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

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 415006.
zixuan-wu added a comment.
Herald added subscribers: llvm-commits, hiraditya.
Herald added a project: LLVM.

Address comments.


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

https://reviews.llvm.org/D121445

Files:
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/CSKY.cpp
  clang/lib/Basic/Targets/CSKY.h
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.h
  clang/lib/Driver/ToolChains/CSKYToolChain.cpp
  clang/lib/Driver/ToolChains/CSKYToolChain.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/bin/ld
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtn.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtn.o
  clang/test/Driver/csky-arch-error.c
  clang/test/Driver/csky-arch.c
  clang/test/Driver/csky-cpus.c
  clang/test/Driver/csky-toolchain.c
  clang/test/Preprocessor/csky-target-features.c
  clang/test/Preprocessor/init-csky.c
  llvm/lib/Target/CSKY/CSKY.h

Index: llvm/lib/Target/CSKY/CSKY.h
===
--- llvm/lib/Target/CSKY/CSKY.h
+++ llvm/lib/Target/CSKY/CSKY.h
@@ -19,6 +19,7 @@
 namespace llvm {
 class CSKYTargetMachine;
 class FunctionPass;
+class PassRegistry;
 
 FunctionPass *createCSKYISelDag(CSKYTargetMachine );
 FunctionPass *createCSKYConstantIslandPass();
Index: clang/test/Preprocessor/init-csky.c
===
--- /dev/null
+++ clang/test/Preprocessor/init-csky.c
@@ -0,0 +1,212 @@
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=CSKY %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky-unknown-linux < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefixes=CSKY,CSKY-LINUX %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky \
+// RUN: -fforce-enable-int128 < /dev/null | FileCheck -match-full-lines \
+// RUN: -check-prefixes=CSKY,CSKY-INT128 %s
+// CSKY: #define _ILP32 1
+// CSKY: #define __ATOMIC_ACQUIRE 2
+// CSKY: #define __ATOMIC_ACQ_REL 4
+// CSKY: #define __ATOMIC_CONSUME 1
+// CSKY: #define __ATOMIC_RELAXED 0
+// CSKY: #define __ATOMIC_RELEASE 3
+// CSKY: #define __ATOMIC_SEQ_CST 5
+// CSKY: #define __BIGGEST_ALIGNMENT__ 4
+// CSKY: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// CSKY: #define __CHAR16_TYPE__ unsigned short
+// CSKY: #define __CHAR32_TYPE__ unsigned int
+// CSKY: #define __CHAR_BIT__ 8
+// CSKY: #define __DBL_DECIMAL_DIG__ 17
+// CSKY: #define __DBL_DENORM_MIN__ 4.9406564584124654e-324
+// CSKY: #define __DBL_DIG__ 15
+// CSKY: #define __DBL_EPSILON__ 2.2204460492503131e-16
+// CSKY: #define __DBL_HAS_DENORM__ 1
+// CSKY: #define __DBL_HAS_INFINITY__ 1
+// CSKY: #define __DBL_HAS_QUIET_NAN__ 1
+// CSKY: #define __DBL_MANT_DIG__ 53
+// CSKY: #define __DBL_MAX_10_EXP__ 308
+// CSKY: #define __DBL_MAX_EXP__ 1024
+// CSKY: #define __DBL_MAX__ 1.7976931348623157e+308
+// CSKY: #define __DBL_MIN_10_EXP__ (-307)
+// CSKY: #define __DBL_MIN_EXP__ (-1021)
+// CSKY: #define __DBL_MIN__ 2.2250738585072014e-308
+// CSKY: #define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
+// CSKY: #define __ELF__ 1
+// CSKY: #define __FINITE_MATH_ONLY__ 0
+// CSKY: #define __FLT_DECIMAL_DIG__ 9
+// CSKY: #define __FLT_DENORM_MIN__ 1.40129846e-45F
+// CSKY: #define __FLT_DIG__ 6
+// CSKY: #define __FLT_EPSILON__ 1.19209290e-7F
+// CSKY: #define __FLT_HAS_DENORM__ 1
+// CSKY: #define __FLT_HAS_INFINITY__ 1
+// CSKY: #define __FLT_HAS_QUIET_NAN__ 1
+// CSKY: #define __FLT_MANT_DIG__ 24
+// CSKY: #define 

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/test/Driver/csky-arch.c:26
+
+// RUN: %clang -target csky-unknown-elf -march=csky -### %s \
+// RUN: -fsyntax-only 2>&1 | FileCheck -check-prefix=CSKY %s

rengolin wrote:
> I don't think this is doing what you expect it to do.
> 
> Depending on the output, you can still match all CHECK lines and not have the 
> output you want.
> 
> To avoid issues, we usually separate tests that must pass (positive tests) 
> like the lines above 24, from tests that must fail (negative tests) like the 
> lines below.
You mean separate into two files or two parts in one file?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121445

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

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: clang/lib/Basic/Targets/CSKY.cpp:43
+  Builder.defineMacro("__CSKYABI__", ABI == "abiv2" ? "2" : "1");
+  Builder.defineMacro("__cskyabi__", ABI == "abiv2" ? "2" : "1");
+

DavidSpickett wrote:
> Any need to handle when ABI is not avbiv2 or abiv1 or will it always be one 
> of the two?
Yes. It always be one of the two.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121445

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

[PATCH] D121445: [Clang][CSKY] Add the CSKY target and compiler driver

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: rengolin, kito.cheng, rsmith, asb, DavidSpickett, 
kaz7.
Herald added subscribers: krytarowski, mgorny.
Herald added a project: All.
zixuan-wu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Add CSKY target toolchains to support csky in linux and elf environment.

It can leverage the basic universal Linux toolchain for linux environment, and 
only add some compile or link parameters. For elf environment, add a 
CSKYToolChain to support compile and link.

Also add some parameters into basic codebase of clang driver.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121445

Files:
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/CSKY.cpp
  clang/lib/Basic/Targets/CSKY.h
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.cpp
  clang/lib/Driver/ToolChains/Arch/CSKY.h
  clang/lib/Driver/ToolChains/CSKYToolChain.cpp
  clang/lib/Driver/ToolChains/CSKYToolChain.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/bin/ld
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/ck860v/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/lib/.keep
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/csky-linux-gnuabiv2/libc/usr/lib/crt1.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/ck860v/crtn.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtbegin.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtend.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crti.o
  
clang/test/Driver/Inputs/multilib_csky_linux_sdk/lib/gcc/csky-linux-gnuabiv2/6.3.0/crtn.o
  clang/test/Driver/csky-arch.c
  clang/test/Driver/csky-cpus.c
  clang/test/Driver/csky-toolchain.c
  clang/test/Preprocessor/csky-target-features.c
  clang/test/Preprocessor/init-csky.c

Index: clang/test/Preprocessor/init-csky.c
===
--- /dev/null
+++ clang/test/Preprocessor/init-csky.c
@@ -0,0 +1,212 @@
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefix=CSKY %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky-unknown-linux < /dev/null \
+// RUN:   | FileCheck -match-full-lines -check-prefixes=CSKY,CSKY-LINUX %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 -triple=csky \
+// RUN: -fforce-enable-int128 < /dev/null | FileCheck -match-full-lines \
+// RUN: -check-prefixes=CSKY,CSKY-INT128 %s
+// CSKY: #define _ILP32 1
+// CSKY: #define __ATOMIC_ACQUIRE 2
+// CSKY: #define __ATOMIC_ACQ_REL 4
+// CSKY: #define __ATOMIC_CONSUME 1
+// CSKY: #define __ATOMIC_RELAXED 0
+// CSKY: #define __ATOMIC_RELEASE 3
+// CSKY: #define __ATOMIC_SEQ_CST 5
+// CSKY: #define __BIGGEST_ALIGNMENT__ 4
+// CSKY: #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+// CSKY: #define __CHAR16_TYPE__ unsigned short
+// CSKY: #define __CHAR32_TYPE__ unsigned int
+// CSKY: #define __CHAR_BIT__ 8
+// CSKY: #define __DBL_DECIMAL_DIG__ 17
+// CSKY: #define __DBL_DENORM_MIN__ 4.9406564584124654e-324
+// CSKY: #define __DBL_DIG__ 15
+// CSKY: #define __DBL_EPSILON__ 2.2204460492503131e-16
+// CSKY: #define __DBL_HAS_DENORM__ 1
+// CSKY: #define __DBL_HAS_INFINITY__ 1
+// CSKY: #define __DBL_HAS_QUIET_NAN__ 1
+// CSKY: #define __DBL_MANT_DIG__ 53
+// CSKY: #define __DBL_MAX_10_EXP__ 308
+// CSKY: #define __DBL_MAX_EXP__ 1024
+// CSKY: #define __DBL_MAX__ 1.7976931348623157e+308
+// CSKY: #define __DBL_MIN_10_EXP__ (-307)
+// CSKY: #define __DBL_MIN_EXP__ (-1021)
+// CSKY: #define __DBL_MIN__ 2.2250738585072014e-308
+// CSKY: #define __DECIMAL_DIG__ __LDBL_DECIMAL_DIG__
+// CSKY: #define __ELF__ 1
+// CSKY: #define __FINITE_MATH_ONLY__ 0
+// CSKY: #define __FLT_DECIMAL_DIG__ 9
+// CSKY: #define __FLT_DENORM_MIN__ 1.40129846e-45F
+// CSKY: #define __FLT_DIG__ 6
+// CSKY: #define __FLT_EPSILON__ 1.19209290e-7F
+// CSKY: #define __FLT_HAS_DENORM__ 1
+// CSKY: #define __FLT_HAS_INFINITY__ 1
+// CSKY: #define __FLT_HAS_QUIET_NAN__ 1
+// CSKY: #define __FLT_MANT_DIG__ 24
+// CSKY: #define __FLT_MAX_10_EXP__ 38

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Sorry for the wrong action of commandeer, @pcwang-thead will still be the 
author.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

It's difficult to run llvm-test-suite in ilp32e abi in Linux. Because there are 
no workable environment such as runtime and kernel for ilp32e in GNU series 
tools.
And we can not run llvm-test-suite in baremental environment(NOT linux but elf 
triple). So I have a question about how to test llvm in elf triple and 
environment? Is there any test case llvm community normally uses and accepts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D70401: [RISCV] Complete RV32E/ilp32e implementation

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu commandeered this revision.
zixuan-wu added a reviewer: pcwang-thead.
zixuan-wu added a comment.

In D70401#3250049 , @khchen wrote:

> 2. Have you try to run llvm-test-suite with rv32e config on qemu?

It's difficult to run llvm-test-suite in ilp32e abi in Linux. Because there are 
no workable environment such as runtime and kernel for ilp32e in GNU series 
tools.
And we can not run llvm-test-suite in baremental environment(NOT linux but elf 
triple). So I have a question about how to test llvm in elf triple and 
environment? Is there any test case llvm community normally uses and accepts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D115921#3224329 , @jrtc27 wrote:

> In D115921#3224324 , @zixuan-wu 
> wrote:
>
>> In D115921#3224284 , @jrtc27 wrote:
>>
>>> but also with RISC-V extensions not being changed once ratified any more 
>>> (changes mean new extensions entirely, not new versions)
>>
>> I don't think so. Or why is there version in RISC-V spec?
>
> That was added years ago before there was any plan/policy for ratifying new 
> extensions beyond the initial GC set. 
> https://docs.google.com/presentation/d/1nQ5uFb39KA6gvUi5SReWfIQSiRN7hp6z7ZPfctE4mKk/edit#slide=id.p1
>  is the current lifecycle; note that //only// errata can be fixed after 
> ratification, everything else requires a new extension (see the blue arrow 
> and brown box below it). As far as I can tell, for new extensions it serves 
> no purpose other than to distinguish draft specs from ratified ones.
>
>> And not only for standard extension, but also it's needed in custom 
>> extension.
>
> Vendor extensions are going to be enough of a support pain in Clang. I 
> sincerely hope they don't make life worse by defining multiple versions, 
> rather than doing it properly and defining new extensions every time they add 
> things. It's not just for the toolchain's benefit; it also improves forwards 
> compatibility for kernels/loaders, as they won't know about new versions, but 
> may know about existing versions, so if they support "Xvendorbase" then 
> software that wants to take advantage of "Xvendorbase" and "Xvendornew" can 
> still use "Xvendorbase", but if the kernel/loader only supports "Xvendor1p0" 
> and software wants to use "Xvendor2p0" then it can't do anything, it'd need 
> to be more careful and also have an "Xvendor1p0" implementation. Extending 
> rather than redefining comes with real benefits.
>
>> BTW, it's been supported to parse version of -march in clang side.
>
> It parses and checks the version, but it only allows //the// version of the 
> extension Clang currently implements. Parsing the version is a hard 
> requirement since it can be part of a valid arch string. Supporting multiple 
> versions is not.

If I don't understand wrong, all you want to say is that the extension version 
is just for indication, and not for functionality? So the RV spec does not 
require compiler to support multi-version.

Anybody else has more comments about support multi-version extension? Or it has 
been decided already?


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

https://reviews.llvm.org/D115921

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/lib/Support/RISCVISAInfo.cpp:48
 {"v", RISCVExtensionVersion{0, 10}},
+//{"v", RISCVExtensionVersion{0, 7}},
 {"zba", RISCVExtensionVersion{1, 0}},

jrtc27 wrote:
> Don't do this
This nit will be removed before commit


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

https://reviews.llvm.org/D115921

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D115921#3224284 , @jrtc27 wrote:

> but also with RISC-V extensions not being changed once ratified any more 
> (changes mean new extensions entirely, not new versions)

I don't think so. Or why is there version in RISC-V spec? 
And not only for standard extension, but also it's needed in custom extension.

BTW, it's been supported to parse version of -march in clang side.


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

https://reviews.llvm.org/D115921

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

ping...


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

https://reviews.llvm.org/D115921

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

[PATCH] D95589: [RISCV] Support experimental 'P' extension 0.9

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added subscribers: VincentWu, luke957, achieveartificialintelligence.

Could abandon it due to D108189 ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95589

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 396148.

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

https://reviews.llvm.org/D115921

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv-arch-version.c
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/attributes-version.ll
  llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test

Index: llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
===
--- llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
+++ llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
@@ -3,7 +3,7 @@
 ## The expected behavior is to ignore the unrecognized arch feature and
 ## continue to process the following arch features.
 ##
-## The object file has the "rv32i2p0_x1p0_m2p0" arch feature. "x1p0" is an
+## The object file has the "rv32i2p0_y1p0_m2p0" arch feature. "y1p0" is an
 ## unrecognized architecture extension. llvm-objdump will ignore it and decode
 ## "mul" instruction correctly according to "m2p0" in the arch feature.
 ##
@@ -34,5 +34,5 @@
 Content: 3385C502
   - Name:.riscv.attributes
 Type:SHT_RISCV_ATTRIBUTES
-## The content is the encoding of the arch feature "rv32i2p0_x1p0_m2p0"
-Content: 4123007269736376000119000572763332693270305F783170305F6D32703000
+## The content is the encoding of the arch feature "rv32i2p0_y1p0_m2p0"
+Content: 4123007269736376000119000572763332693270305F793170305F6D32703000
Index: llvm/test/CodeGen/RISCV/attributes-version.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/attributes-version.ll
@@ -0,0 +1,81 @@
+; Generate ELF attributes from llc.
+
+; RUN: llc -mtriple=riscv32 -mattr=+m %s -o - | FileCheck --check-prefix=RV32M %s
+; RUN: llc -mtriple=riscv32 -mattr=+a %s -o - | FileCheck --check-prefix=RV32A %s
+; RUN: llc -mtriple=riscv32 -mattr=+f %s -o - | FileCheck --check-prefix=RV32F %s
+; RUN: llc -mtriple=riscv32 -mattr=+d %s -o - | FileCheck --check-prefix=RV32D %s
+; RUN: llc -mtriple=riscv32 -mattr=+c %s -o - | FileCheck --check-prefix=RV32C %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zfhmin %s -o - | FileCheck --check-prefix=RV32ZFHMIN %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zfh %s -o - | FileCheck --check-prefix=RV32ZFH %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zba %s -o - | FileCheck --check-prefix=RV32ZBA %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbb %s -o - | FileCheck --check-prefix=RV32ZBB %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbc %s -o - | FileCheck --check-prefix=RV32ZBC %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbe %s -o - | FileCheck --check-prefix=RV32ZBE %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbf %s -o - | FileCheck --check-prefix=RV32ZBF %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbm %s -o - | FileCheck --check-prefix=RV32ZBM %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbp %s -o - | FileCheck --check-prefix=RV32ZBP %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbr %s -o - | FileCheck --check-prefix=RV32ZBR %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbs %s -o - | FileCheck --check-prefix=RV32ZBS %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbt %s -o - | FileCheck --check-prefix=RV32ZBT %s
+
+
+; RV32M: .attribute 5, "rv32i2p0_m2p0"
+; RV32A: .attribute 5, "rv32i2p0_a2p0"
+; RV32F: .attribute 5, "rv32i2p0_f2p0"
+; RV32D: .attribute 5, "rv32i2p0_f2p0_d2p0"
+; RV32C: .attribute 5, "rv32i2p0_c2p0"
+; RV32V: .attribute 5, "rv32i2p0_v0p10_zvlsseg0p10"
+; RV32ZFHMIN: .attribute 5, "rv32i2p0_f2p0_zfhmin0p1"
+; RV32ZFH: .attribute 5, "rv32i2p0_f2p0_zfh0p1_zfhmin0p1"
+; RV32ZBA: .attribute 5, "rv32i2p0_zba1p0"
+; RV32ZBB: .attribute 5, "rv32i2p0_zbb1p0"
+; RV32ZBC: .attribute 5, "rv32i2p0_zbc1p0"
+; RV32ZBE: .attribute 5, "rv32i2p0_zbe0p93"
+; RV32ZBF: .attribute 5, "rv32i2p0_zbf0p93"
+; RV32ZBM: .attribute 5, "rv32i2p0_zbm0p93"
+; RV32ZBP: .attribute 5, "rv32i2p0_zbp0p93"
+; RV32ZBR: .attribute 5, "rv32i2p0_zbr0p93"
+; RV32ZBS: .attribute 5, "rv32i2p0_zbs1p0"
+; RV32ZBT: .attribute 5, "rv32i2p0_zbt0p93"
+
+
+; RUN: llc -mtriple=riscv32 -mattr=+m0p7 < %s 2>&1 | FileCheck --check-prefix=RV32M0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+a0p7 < %s 2>&1 | FileCheck --check-prefix=RV32A0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+f0p7 < %s 2>&1 | FileCheck --check-prefix=RV32F0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+d0p7 < %s 2>&1 | FileCheck --check-prefix=RV32D0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+c0p7 < %s 2>&1 | FileCheck --check-prefix=RV32C0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zfhmin0p7 < %s 2>&1 

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/include/llvm/Support/RISCVISAInfo.h:33
+  bool operator!=(const RISCVExtensionVersion ) const {
+return !operator==(Version);
+  }

craig.topper wrote:
> Use `!(*this == Version)`
Good taste.



Comment at: llvm/lib/Target/RISCV/RISCVSubtarget.cpp:91
 StringRef ABIName) {
+  initializeEnvironment();
   // Determine default and user-specified characteristics

craig.topper wrote:
> Why do we need to initialize things now but didn't before?
After the constructor is workable to initialize, no need for 
initializeEnvironment. So remove it.


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

https://reviews.llvm.org/D115921

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 396147.
zixuan-wu edited the summary of this revision.
zixuan-wu added a comment.

Address all comments.


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

https://reviews.llvm.org/D115921

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv-arch-version.c
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVSubtarget.cpp
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/attributes-version.ll
  llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test

Index: llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
===
--- llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
+++ llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
@@ -3,7 +3,7 @@
 ## The expected behavior is to ignore the unrecognized arch feature and
 ## continue to process the following arch features.
 ##
-## The object file has the "rv32i2p0_x1p0_m2p0" arch feature. "x1p0" is an
+## The object file has the "rv32i2p0_y1p0_m2p0" arch feature. "y1p0" is an
 ## unrecognized architecture extension. llvm-objdump will ignore it and decode
 ## "mul" instruction correctly according to "m2p0" in the arch feature.
 ##
@@ -34,5 +34,5 @@
 Content: 3385C502
   - Name:.riscv.attributes
 Type:SHT_RISCV_ATTRIBUTES
-## The content is the encoding of the arch feature "rv32i2p0_x1p0_m2p0"
-Content: 4123007269736376000119000572763332693270305F783170305F6D32703000
+## The content is the encoding of the arch feature "rv32i2p0_y1p0_m2p0"
+Content: 4123007269736376000119000572763332693270305F793170305F6D32703000
Index: llvm/test/CodeGen/RISCV/attributes-version.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/attributes-version.ll
@@ -0,0 +1,81 @@
+; Generate ELF attributes from llc.
+
+; RUN: llc -mtriple=riscv32 -mattr=+m %s -o - | FileCheck --check-prefix=RV32M %s
+; RUN: llc -mtriple=riscv32 -mattr=+a %s -o - | FileCheck --check-prefix=RV32A %s
+; RUN: llc -mtriple=riscv32 -mattr=+f %s -o - | FileCheck --check-prefix=RV32F %s
+; RUN: llc -mtriple=riscv32 -mattr=+d %s -o - | FileCheck --check-prefix=RV32D %s
+; RUN: llc -mtriple=riscv32 -mattr=+c %s -o - | FileCheck --check-prefix=RV32C %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zfhmin %s -o - | FileCheck --check-prefix=RV32ZFHMIN %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zfh %s -o - | FileCheck --check-prefix=RV32ZFH %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zba %s -o - | FileCheck --check-prefix=RV32ZBA %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbb %s -o - | FileCheck --check-prefix=RV32ZBB %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbc %s -o - | FileCheck --check-prefix=RV32ZBC %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbe %s -o - | FileCheck --check-prefix=RV32ZBE %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbf %s -o - | FileCheck --check-prefix=RV32ZBF %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbm %s -o - | FileCheck --check-prefix=RV32ZBM %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbp %s -o - | FileCheck --check-prefix=RV32ZBP %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbr %s -o - | FileCheck --check-prefix=RV32ZBR %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbs %s -o - | FileCheck --check-prefix=RV32ZBS %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbt %s -o - | FileCheck --check-prefix=RV32ZBT %s
+
+
+; RV32M: .attribute 5, "rv32i2p0_m2p0"
+; RV32A: .attribute 5, "rv32i2p0_a2p0"
+; RV32F: .attribute 5, "rv32i2p0_f2p0"
+; RV32D: .attribute 5, "rv32i2p0_f2p0_d2p0"
+; RV32C: .attribute 5, "rv32i2p0_c2p0"
+; RV32V: .attribute 5, "rv32i2p0_v0p10_zvlsseg0p10"
+; RV32ZFHMIN: .attribute 5, "rv32i2p0_f2p0_zfhmin0p1"
+; RV32ZFH: .attribute 5, "rv32i2p0_f2p0_zfh0p1_zfhmin0p1"
+; RV32ZBA: .attribute 5, "rv32i2p0_zba1p0"
+; RV32ZBB: .attribute 5, "rv32i2p0_zbb1p0"
+; RV32ZBC: .attribute 5, "rv32i2p0_zbc1p0"
+; RV32ZBE: .attribute 5, "rv32i2p0_zbe0p93"
+; RV32ZBF: .attribute 5, "rv32i2p0_zbf0p93"
+; RV32ZBM: .attribute 5, "rv32i2p0_zbm0p93"
+; RV32ZBP: .attribute 5, "rv32i2p0_zbp0p93"
+; RV32ZBR: .attribute 5, "rv32i2p0_zbr0p93"
+; RV32ZBS: .attribute 5, "rv32i2p0_zbs1p0"
+; RV32ZBT: .attribute 5, "rv32i2p0_zbt0p93"
+
+
+; RUN: llc -mtriple=riscv32 -mattr=+m0p7 < %s 2>&1 | FileCheck --check-prefix=RV32M0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+a0p7 < %s 2>&1 | FileCheck --check-prefix=RV32A0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+f0p7 < %s 2>&1 | FileCheck --check-prefix=RV32F0P7 %s
+; RUN: llc -mtriple=riscv32 -mattr=+d0p7 < %s 2>&1 | FileCheck --check-prefix=RV32D0P7 %s
+; RUN: llc 

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D115921#3206156 , @jrtc27 wrote:

> Do not bring back V draft 0.7. It is gone, it will never be supported again 
> by LLVM under that name. The standard extension namespace is reserved for 
> ratified extensions and development snapshots only, not old drafts vendors 
> decided to ship. For those, non-standard extension names are needed.

I understood only ratified extension is accepted. Even for ratified extension, 
the version is going to evolve in the future. So this patch is for that. v0p7 
is just used to go through the codepath to support multiple version and test as 
now there is no extension that is not the default version. I will change the 
test way.


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

https://reviews.llvm.org/D115921

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu updated this revision to Diff 395803.
zixuan-wu edited the summary of this revision.
zixuan-wu added a comment.

Address comments.


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

https://reviews.llvm.org/D115921

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/Driver/riscv-arch.c
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVSubtarget.cpp
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/attributes.ll
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test

Index: llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
===
--- llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
+++ llvm/test/tools/llvm-objdump/ELF/RISCV/unknown-arch-attr.test
@@ -3,7 +3,7 @@
 ## The expected behavior is to ignore the unrecognized arch feature and
 ## continue to process the following arch features.
 ##
-## The object file has the "rv32i2p0_x1p0_m2p0" arch feature. "x1p0" is an
+## The object file has the "rv32i2p0_y1p0_m2p0" arch feature. "y1p0" is an
 ## unrecognized architecture extension. llvm-objdump will ignore it and decode
 ## "mul" instruction correctly according to "m2p0" in the arch feature.
 ##
@@ -34,5 +34,5 @@
 Content: 3385C502
   - Name:.riscv.attributes
 Type:SHT_RISCV_ATTRIBUTES
-## The content is the encoding of the arch feature "rv32i2p0_x1p0_m2p0"
-Content: 4123007269736376000119000572763332693270305F783170305F6D32703000
+## The content is the encoding of the arch feature "rv32i2p0_y1p0_m2p0"
+Content: 4123007269736376000119000572763332693270305F793170305F6D32703000
Index: llvm/test/MC/RISCV/attribute-arch.s
===
--- llvm/test/MC/RISCV/attribute-arch.s
+++ llvm/test/MC/RISCV/attribute-arch.s
@@ -76,3 +76,6 @@
 
 .attribute arch, "rv32iv0p10zvlsseg0p10"
 # CHECK: attribute  5, "rv32i2p0_v0p10_zvlsseg0p10"
+
+.attribute arch, "rv32iv0p7zvlsseg0p7"
+# CHECK: attribute  5, "rv32i2p0_v0p7_zvlsseg0p7"
Index: llvm/test/CodeGen/RISCV/attributes.ll
===
--- llvm/test/CodeGen/RISCV/attributes.ll
+++ llvm/test/CodeGen/RISCV/attributes.ll
@@ -17,6 +17,7 @@
 ; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbr %s -o - | FileCheck --check-prefix=RV32ZBR %s
 ; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbs %s -o - | FileCheck --check-prefix=RV32ZBS %s
 ; RUN: llc -mtriple=riscv32 -mattr=+experimental-zbt %s -o - | FileCheck --check-prefix=RV32ZBT %s
+; RUN: llc -mtriple=riscv32 -mattr=+experimental-v0p7 %s -o - | FileCheck --check-prefix=RV32V0P7 %s
 ; RUN: llc -mtriple=riscv64 -mattr=+m %s -o - | FileCheck --check-prefix=RV64M %s
 ; RUN: llc -mtriple=riscv64 -mattr=+a %s -o - | FileCheck --check-prefix=RV64A %s
 ; RUN: llc -mtriple=riscv64 -mattr=+f %s -o - | FileCheck --check-prefix=RV64F %s
@@ -34,6 +35,7 @@
 ; RUN: llc -mtriple=riscv64 -mattr=+experimental-zbr %s -o - | FileCheck --check-prefix=RV64ZBR %s
 ; RUN: llc -mtriple=riscv64 -mattr=+experimental-zbs %s -o - | FileCheck --check-prefix=RV64ZBS %s
 ; RUN: llc -mtriple=riscv64 -mattr=+experimental-zbt %s -o - | FileCheck --check-prefix=RV64ZBT %s
+; RUN: llc -mtriple=riscv64 -mattr=+experimental-v0p7 %s -o - | FileCheck --check-prefix=RV64V0P7 %s
 
 ; RV32M: .attribute 5, "rv32i2p0_m2p0"
 ; RV32A: .attribute 5, "rv32i2p0_a2p0"
@@ -53,6 +55,7 @@
 ; RV32ZBR: .attribute 5, "rv32i2p0_zbr0p93"
 ; RV32ZBS: .attribute 5, "rv32i2p0_zbs1p0"
 ; RV32ZBT: .attribute 5, "rv32i2p0_zbt0p93"
+; RV32V0P7: .attribute 5, "rv32i2p0_v0p7_zvlsseg0p7"
 ; RV32COMBINED: .attribute 5, "rv32i2p0_f2p0_v0p10_zfh0p1_zfhmin0p1_zbb1p0_zvlsseg0p10"
 
 ; RV64M: .attribute 5, "rv64i2p0_m2p0"
@@ -73,6 +76,7 @@
 ; RV64ZBS: .attribute 5, "rv64i2p0_zbs1p0"
 ; RV64ZBT: .attribute 5, "rv64i2p0_zbt0p93"
 ; RV64V: .attribute 5, "rv64i2p0_v0p10_zvlsseg0p10"
+; RV64V0P7: .attribute 5, "rv64i2p0_v0p7_zvlsseg0p7"
 ; RV64COMBINED: .attribute 5, "rv64i2p0_f2p0_v0p10_zfh0p1_zfhmin0p1_zbb1p0_zvlsseg0p10"
 
 
Index: llvm/lib/Target/RISCV/RISCVSubtarget.h
===
--- llvm/lib/Target/RISCV/RISCVSubtarget.h
+++ llvm/lib/Target/RISCV/RISCVSubtarget.h
@@ -24,6 +24,7 @@
 #include "llvm/CodeGen/SelectionDAGTargetInfo.h"
 #include "llvm/CodeGen/TargetSubtargetInfo.h"
 #include "llvm/IR/DataLayout.h"
+#include "llvm/Support/RISCVISAInfo.h"
 #include "llvm/Target/TargetMachine.h"
 
 #define GET_SUBTARGETINFO_HEADER
@@ -34,27 +35,28 @@
 
 class RISCVSubtarget : public RISCVGenSubtargetInfo {
   virtual void anchor();
-  bool HasStdExtM = false;
-  bool HasStdExtA = false;
-  bool 

[PATCH] D115923: [RISCV][Don't Commit] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu abandoned this revision.
zixuan-wu added a comment.

Only need review D115921 . Just abandon it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115923

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D115921#3201346 , @luismarques 
wrote:

>> enable 'm' extension with passing mattr=+m After this patch, it would be 
>> -mattr=+m2p0.
>
> It's not obvious to me that support for extension versions should mean or has 
> to mean that we always explicitly specify the version. Why can't we keep 
> supporting the option `mattr=+m`, which would be mapped to `mattr=+m,+m2p0`, 
> or whatever the current default `m` version happens to be?

OK. I think default version mattr is acceptable. And then testcases change 
would be clean and simple.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115921

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

[PATCH] D115921: [RISCV] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: asb, craig.topper, kito-cheng, luismarques, apazos, 
jrtc27, Jim, akuegel.
Herald added subscribers: VincentWu, luke957, achieveartificialintelligence, 
armkevincheng, eric-k256, vkmr, frasercrmck, jdoerfert, evandro, 
sameer.abuasal, s.egerton, benna, psnobl, jocewei, rupprecht, PkmX, arphaman, 
the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, niosHD, 
sabuasal, simoncook, johnrusso, rbar, hiraditya, emaste, qcolombet, MatzeB.
Herald added a reviewer: jhenderson.
Herald added a reviewer: MaskRay.
Herald added a reviewer: sjarus.
zixuan-wu requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

As RISC-V spec supports multiple extension version, refactor the 
SubtargetFeatures and RISCVISAInfo to support it.

RISCVISAInfo can parse arch string like -march with extension version, but 
related SubtargetFeatures don't contain version info in llvm side. For example, 
SubtargetFeature name is "m" when enable 'm' extension with passing 
`-mattr=+m`. After this patch, it would be `-mattr=+m2p0`.

It also handles arch string with version number of attribute section in obj 
file, including assemble and dis-assemble process.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115921

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/test/CodeGen/RISCV/riscv-attr-builtin-alias-err.c
  clang/test/CodeGen/RISCV/riscv-attr-builtin-alias.c
  clang/test/CodeGen/RISCV/riscv-inline-asm-rvv.c
  clang/test/CodeGen/RISCV/riscv-v-debuginfo.c
  clang/test/CodeGen/RISCV/riscv-v-lifetime.cpp
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb-error.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbb.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbc.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbe.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbp.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbr.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbb.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbc.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbe.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbp.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbr.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vaadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vadc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vand.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vasub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vcompress.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vcpop.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfabs.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfclass.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfcvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfirst.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmerge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfncvt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfneg.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrdiv.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrec7.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredmax.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredmin.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfredsum.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrsqrt7.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfrsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsgnj.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfslide1down.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfslide1up.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsqrt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwadd.c
  

[PATCH] D115923: [RISCV][Don't Commit] Refactor the RISCV ISA extension info and target features to support multiple extension version

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu created this revision.
zixuan-wu added reviewers: asb, craig.topper, kito-cheng, luismarques, apazos, 
jrtc27, Jim, akuegel, jhenderson, MaskRay, sjarus.
Herald added subscribers: VincentWu, luke957, achieveartificialintelligence, 
vkmr, frasercrmck, evandro, sameer.abuasal, s.egerton, benna, psnobl, jocewei, 
PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, niosHD, 
sabuasal, simoncook, johnrusso, rbar, hiraditya.
zixuan-wu requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Split from https://reviews.llvm.org/D115921 since testcase change is too large 
to review.

This is part of D115921 , and will not be 
committed.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115923

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/lib/Basic/Targets/RISCV.cpp
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp
  clang/utils/TableGen/RISCVVEmitter.cpp
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Object/ELFObjectFile.cpp
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h

Index: llvm/lib/Target/RISCV/RISCVSubtarget.h
===
--- llvm/lib/Target/RISCV/RISCVSubtarget.h
+++ llvm/lib/Target/RISCV/RISCVSubtarget.h
@@ -24,6 +24,7 @@
 #include "llvm/CodeGen/SelectionDAGTargetInfo.h"
 #include "llvm/CodeGen/TargetSubtargetInfo.h"
 #include "llvm/IR/DataLayout.h"
+#include "llvm/Support/RISCVISAInfo.h"
 #include "llvm/Target/TargetMachine.h"
 
 #define GET_SUBTARGETINFO_HEADER
@@ -34,28 +35,28 @@
 
 class RISCVSubtarget : public RISCVGenSubtargetInfo {
   virtual void anchor();
-  bool HasStdExtM = false;
-  bool HasStdExtA = false;
-  bool HasStdExtF = false;
-  bool HasStdExtD = false;
-  bool HasStdExtC = false;
-  bool HasStdExtZba = false;
-  bool HasStdExtZbb = false;
-  bool HasStdExtZbc = false;
-  bool HasStdExtZbe = false;
-  bool HasStdExtZbf = false;
-  bool HasStdExtZbm = false;
-  bool HasStdExtZbp = false;
-  bool HasStdExtZbr = false;
-  bool HasStdExtZbs = false;
-  bool HasStdExtZbt = false;
-  bool HasStdExtV = false;
-  bool HasStdExtZvlsseg = false;
-  bool HasStdExtZvamo = false;
-  bool HasStdExtZfhmin = false;
-  bool HasStdExtZfh = false;
+  RISCVExtensionVersion StdExtM = {0, 0};
+  RISCVExtensionVersion StdExtA = {0, 0};
+  RISCVExtensionVersion StdExtF = {0, 0};
+  RISCVExtensionVersion StdExtD = {0, 0};
+  RISCVExtensionVersion StdExtC = {0, 0};
+  RISCVExtensionVersion StdExtZba = {0, 0};
+  RISCVExtensionVersion StdExtZbb = {0, 0};
+  RISCVExtensionVersion StdExtZbc = {0, 0};
+  RISCVExtensionVersion StdExtZbe = {0, 0};
+  RISCVExtensionVersion StdExtZbf = {0, 0};
+  RISCVExtensionVersion StdExtZbm = {0, 0};
+  RISCVExtensionVersion StdExtZbp = {0, 0};
+  RISCVExtensionVersion StdExtZbr = {0, 0};
+  RISCVExtensionVersion StdExtZbs = {0, 0};
+  RISCVExtensionVersion StdExtZbt = {0, 0};
+  RISCVExtensionVersion StdExtV = {0, 0};
+  RISCVExtensionVersion StdExtZvlsseg = {0, 0};
+  RISCVExtensionVersion StdExtZvamo = {0, 0};
+  RISCVExtensionVersion StdExtZfhmin = {0, 0};
+  RISCVExtensionVersion StdExtZfh = {0, 0};
+  RISCVExtensionVersion StdExtE = {0, 0};
   bool HasRV64 = false;
-  bool IsRV32E = false;
   bool EnableLinkerRelax = false;
   bool EnableRVCHintInstrs = true;
   bool EnableSaveRestore = false;
@@ -101,28 +102,34 @@
 return 
   }
   bool enableMachineScheduler() const override { return true; }
-  bool hasStdExtM() const { return HasStdExtM; }
-  bool hasStdExtA() const { return HasStdExtA; }
-  bool hasStdExtF() const { return HasStdExtF; }
-  bool hasStdExtD() const { return HasStdExtD; }
-  bool hasStdExtC() const { return HasStdExtC; }
-  bool hasStdExtZba() const { return HasStdExtZba; }
-  bool hasStdExtZbb() const { return HasStdExtZbb; }
-  bool hasStdExtZbc() const { return HasStdExtZbc; }
-  bool hasStdExtZbe() const { return HasStdExtZbe; }
-  bool hasStdExtZbf() const { return HasStdExtZbf; }
-  bool hasStdExtZbm() const { return HasStdExtZbm; }
-  bool hasStdExtZbp() const { return HasStdExtZbp; }
-  bool hasStdExtZbr() const { return HasStdExtZbr; }
-  bool hasStdExtZbs() const { return HasStdExtZbs; }
-  bool hasStdExtZbt() const { return HasStdExtZbt; }
-  bool hasStdExtV() const { return HasStdExtV; }
-  bool hasStdExtZvlsseg() const { return HasStdExtZvlsseg; }
-  bool hasStdExtZvamo() const { return HasStdExtZvamo; }
-  bool hasStdExtZfhmin() const { return HasStdExtZfhmin; }
-  bool hasStdExtZfh() const { return HasStdExtZfh; }
+  bool hasStdExtM() const { return StdExtM != RISCVExtensionVersion{0, 0}; }
+  bool hasStdExtA() const { return StdExtA != RISCVExtensionVersion{0, 0}; }
+  bool hasStdExtF() const { return StdExtF != RISCVExtensionVersion{0, 0}; }
+  bool hasStdExtD() const { return StdExtD != 

[PATCH] D108189: [RISCV] Support experimental 'P' extension 0.96

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added subscribers: VincentWu, luke957, achieveartificialintelligence.

Hi, @Jim.
What time is P extension going to upstream to community since it's been no 
update for some months?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108189

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

[PATCH] D70401: [WIP][RISCV] Implement ilp32e ABI

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a subscriber: pcwang-thead.
zixuan-wu added a comment.

In D70401#3175266 , @khchen wrote:

>> Is it (D70401 ) good enough to solve or 
>> complete rv32e issue?
>
> It need to
>
> 1. disallow ilp32e ABI with D ISA extension. 
> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/3f81fae0412bb9ad4002a4ade508be7aa5e1599b/riscv-cc.adoc#ilp32e-calling-convention
> 2. emit predefined marco in header (`__riscv_e`)
> 3. markSuperRegs for X16-X31
> 4. update tests after rebase on main.

Nice. If no body objects, @pcwang-thead will take this task and re-draft a 
review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D70401: [WIP][RISCV] Implement ilp32e ABI

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D70401#3172750 , @khchen wrote:

> In D70401#3172457 , @zixuan-wu wrote:
>
>> Hi, all. Why is it not continued?
>
> Sorry, I have to work on other tasks so stop the rv32e implementation work.
> Are you interest to finish it? I could share my patches to you.

Is it (D70401 ) good enough to solve or 
complete rv32e issue?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D70401: [WIP][RISCV] Implement ilp32e ABI

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added subscribers: VincentWu, luke957, achieveartificialintelligence.

Hi, all. Why is it not continued?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70401

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

[PATCH] D112921: [clang] Enable sized deallocation by default in C++14 onwards

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

Is this going to be reviewed again or committed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112921

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

[PATCH] D8467: C++14: Disable sized deallocation by default due to ABI breakage

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.

In D8467#3125313 , @tstellar wrote:

> In D8467#3095610 , @zixuan-wu wrote:
>
>> Hi, I am wondering could -fsized-deallocation this be enabled by default 
>> nowadays in 2021?
>
> Were you planning to work on this?

It's been working on at https://reviews.llvm.org/D112921


Repository:
  rL LLVM

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

https://reviews.llvm.org/D8467

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

[PATCH] D105168: [RISCV] Unify the arch string parsing logic to RISCVISAInfo.

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added subscribers: VincentWu, luke957.

Hi, @kito-cheng as your this patch unify the extension handing in one same 
place by new infra, are you going to support the multiple extension version in 
next step?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105168

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

[PATCH] D8467: C++14: Disable sized deallocation by default due to ABI breakage

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added a comment.
Herald added a subscriber: dang.

Hi, I am wondering could -fsized-deallocation this be enabled by default 
nowadays in 2021?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D8467

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

[PATCH] D105168: [RISCV] Unify the arch string parsing logic to RISCVISAInfo.

[Zixuan Wu via Phabricator via cfe-commits]

zixuan-wu added inline comments.



Comment at: llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.cpp:107
+  for (auto Feature : RISCVFeatureKV) {
+if (FeatureBits[Feature.Value] &&
+llvm::RISCVISAInfo::isSupportedExtensionFeature(Feature.Key))

If SubtargetFeature is enum value like ARM.td does, Feature.Value would be a 
uninitialization value, so I think there should be if condition like  
`Feature.Value < RISCV::NumSubtargetFeatures`, or there is a out-of-range visit.

```
def ProcXXX :
  SubtargetFeature<"", "RISCVProcFamily",
   "XXX", "XXX processors">;
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105168

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