[llvm-branch-commits] [lld] [llvm] release/18.x: [LoongArch] Use R_LARCH_ALIGN with section symbol (#84741) (PR #88891)

[Lu Weining via llvm-branch-commits]

SixWeining wrote:

This will be reverted in main branch 
(https://github.com/llvm/llvm-project/pull/92584). So close it.

https://github.com/llvm/llvm-project/pull/88891
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [lld] [llvm] release/18.x: [LoongArch] Use R_LARCH_ALIGN with section symbol (#84741) (PR #88891)

[Lu Weining via llvm-branch-commits]

https://github.com/SixWeining closed 
https://github.com/llvm/llvm-project/pull/88891
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [LoongArch] Suppress the unnecessary extensions for arguments in makeLibCall (PR #92376)

[Lu Weining via llvm-branch-commits]

https://github.com/SixWeining approved this pull request.


https://github.com/llvm/llvm-project/pull/92376
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [LoongArch] Use sign extend for i32 arguments in makeLibCall on LA64 (PR #92375)

[Lu Weining via llvm-branch-commits]

https://github.com/SixWeining approved this pull request.

LGTM. I think this fix should be check-picked to 18.x.

https://github.com/llvm/llvm-project/pull/92375
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [LoongArch] Refactor LoongArchABI::computeTargetABI (PR #92223)

[Lu Weining via llvm-branch-commits]

https://github.com/SixWeining approved this pull request.


https://github.com/llvm/llvm-project/pull/92223
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [LoongArch] Refactor LoongArchABI::computeTargetABI (PR #92223)

[Lu Weining via llvm-branch-commits]

@@ -49,63 +50,127 @@ static ABI checkABIStandardized(ABI Abi) {
   return Abi;
 }
 
-ABI computeTargetABI(const Triple , StringRef ABIName) {
-  ABI ArgProvidedABI = getTargetABI(ABIName);
+static ABI getTripleABI(const Triple ) {
   bool Is64Bit = TT.isArch64Bit();
   ABI TripleABI;
-
-  // Figure out the ABI explicitly requested via the triple's environment type.
   switch (TT.getEnvironment()) {
   case llvm::Triple::EnvironmentType::GNUSF:
-TripleABI = Is64Bit ? LoongArchABI::ABI_LP64S : LoongArchABI::ABI_ILP32S;
+TripleABI = Is64Bit ? ABI_LP64S : ABI_ILP32S;
 break;
   case llvm::Triple::EnvironmentType::GNUF32:
-TripleABI = Is64Bit ? LoongArchABI::ABI_LP64F : LoongArchABI::ABI_ILP32F;
+TripleABI = Is64Bit ? ABI_LP64F : ABI_ILP32F;
 break;
-
   // Let the fallback case behave like {ILP32,LP64}D.
   case llvm::Triple::EnvironmentType::GNUF64:
   default:
-TripleABI = Is64Bit ? LoongArchABI::ABI_LP64D : LoongArchABI::ABI_ILP32D;
+TripleABI = Is64Bit ? ABI_LP64D : ABI_ILP32D;
 break;
   }
+  return TripleABI;
+}
 
-  switch (ArgProvidedABI) {
-  case LoongArchABI::ABI_Unknown:
-// Fallback to the triple-implied ABI if ABI name is not specified or
-// invalid.
-if (!ABIName.empty())
-  errs() << "'" << ABIName
- << "' is not a recognized ABI for this target, ignoring and using 
"
-"triple-implied ABI\n";
-return checkABIStandardized(TripleABI);
+ABI computeTargetABI(const Triple , const FeatureBitset ,
+ StringRef ABIName) {
+  bool Is64Bit = TT.isArch64Bit();
+  ABI ArgProvidedABI = getTargetABI(ABIName);
+  ABI TripleABI = getTripleABI(TT);
+
+  auto GetFeatureABI = [=]() {

SixWeining wrote:

Maybe move it to where it is called (i.e. line 173) for better readability?

https://github.com/llvm/llvm-project/pull/92223
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [LoongArch][Codegen] Add support for TLSDESC (PR #90159)

[Lu Weining via llvm-branch-commits]

https://github.com/SixWeining approved this pull request.

LGTM except a nit.

https://github.com/llvm/llvm-project/pull/90159
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [LoongArch][Codegen] Add support for TLSDESC (PR #90159)

[Lu Weining via llvm-branch-commits]

@@ -737,7 +737,7 @@ bool tools::isTLSDESCEnabled(const ToolChain ,
   StringRef V = A->getValue();
   bool SupportedArgument = false, EnableTLSDESC = false;
   bool Unsupported = !Triple.isOSBinFormatELF();
-  if (Triple.isRISCV()) {
+  if (Triple.isRISCV() || Triple.isLoongArch()) {

SixWeining wrote:

Is it better to sort alphabetically?

https://github.com/llvm/llvm-project/pull/90159
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [LoongArch][Codegen] Add support for TLSDESC (PR #90159)

[Lu Weining via llvm-branch-commits]

https://github.com/SixWeining edited 
https://github.com/llvm/llvm-project/pull/90159
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [lld] [llvm] release/18.x: [LoongArch] Use R_LARCH_ALIGN with section symbol (#84741) (PR #88891)

[Lu Weining via llvm-branch-commits]

https://github.com/SixWeining approved this pull request.

Binutils has made same change and to keep compatibility we have to cherry-pick 
it to 18.x.

https://github.com/llvm/llvm-project/pull/88891
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [clang] release/18.x: [Clang][LoongArch] Fix wrong return value type of __iocsrrd_h (#84100) (PR #84715)

[Lu Weining via llvm-branch-commits]

https://github.com/SixWeining approved this pull request.


https://github.com/llvm/llvm-project/pull/84715
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/18.x: [llvm][LoongArch] Improve loongarch_lasx_xvpermi_q instrinsic (#82984) (PR #83540)

[Lu Weining via llvm-branch-commits]

SixWeining wrote:

> For the record, based on the principle of "explicit is better than implicit" 
> that generally holds, I'd favor an approach where such 
> compile-time-verifiable out-of-range operands are given compile-time errors, 
> or we should just pass through the value unmodified. Otherwise the intrinsic 
> would have to carry the workaround effectively forever, and we could find 
> ourselves trapped if later micro-architectures actually start to make use of 
> the currently cleared bits.

Makes sense. After discussion with gcc-loongarch team, we both decide to revert 
this change. Thanks.

https://github.com/llvm/llvm-project/pull/83540
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/18.x: [llvm][LoongArch] Improve loongarch_lasx_xvpermi_q instrinsic (#82984) (PR #83540)

[Lu Weining via llvm-branch-commits]

https://github.com/SixWeining closed 
https://github.com/llvm/llvm-project/pull/83540
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [llvm] release/18.x: [llvm][LoongArch] Improve loongarch_lasx_xvpermi_q instrinsic (#82984) (PR #83540)

[Lu Weining via llvm-branch-commits]

SixWeining wrote:

> I have some doubt about this change.
> 
> To me if the user requests `xvpermi.q` via the `loongarch_lasx_xvpermi_q` 
> intrinsic, we should give her/him the `xvpermi.q` instruction. If (s)he is 
> passing an invalid operand then (s)he is invoking the undefined behavior 
> herself/himself and we don't need to guarantee a thing.
> 
> So to me we should not merge this and we should revert this change for main. 
> Or am I missing something? @xen0n @heiher @SixWeining @MaskRay

Yes, it can be argued. But I know gcc has similar change.

https://github.com/llvm/llvm-project/pull/83540
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits

[llvm-branch-commits] [lld] PR for llvm/llvm-project#80789 (PR #80790)

[Lu Weining via llvm-branch-commits]

SixWeining wrote:

> @SixWeining What do you think about merging this PR to the release branch?

Looks good to me. As LoongArch gcc/binutils have began generating relax 
relocations for about 1 year, lld needs this PR so that it can link fundamental 
system objects (such as Scrt1.o). People have reached a consensus about this 
cherry-picking (See https://github.com/llvm/llvm-project/pull/78692).

https://github.com/llvm/llvm-project/pull/80790
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits