Page MenuHomePhabricator

benshi001 (Ben Shi)
User

Projects

User does not belong to any projects.

User Details

User Since
Jun 6 2020, 5:03 AM (45 w, 1 d)

Recent Activity

Sat, Apr 17

benshi001 added a comment to D100701: [clang][AVR] Redefine some types to be compatible with avr-gcc.

Though the disabled test builtins.cpp can pass after my another patch https://reviews.llvm.org/D97669, it will still fail on llvm build machines, since there are no avr-libc installed on them.

Sat, Apr 17, 5:11 AM · Restricted Project
benshi001 added a comment to D100701: [clang][AVR] Redefine some types to be compatible with avr-gcc.

Some key points,

Sat, Apr 17, 5:01 AM · Restricted Project
benshi001 requested review of D100701: [clang][AVR] Redefine some types to be compatible with avr-gcc.
Sat, Apr 17, 4:16 AM · Restricted Project

Fri, Apr 16

benshi001 committed rG06995fe256ec: [clang][NFC] Fix a potential assert failure (authored by benshi001).
[clang][NFC] Fix a potential assert failure
Fri, Apr 16, 4:18 PM
benshi001 closed D100616: [clang][NFC] Fix a potential assert failure.
Fri, Apr 16, 4:17 PM · Restricted Project
benshi001 added inline comments to D100616: [clang][NFC] Fix a potential assert failure.
Fri, Apr 16, 3:07 AM · Restricted Project
benshi001 updated the diff for D100616: [clang][NFC] Fix a potential assert failure.
Fri, Apr 16, 3:06 AM · Restricted Project

Thu, Apr 15

benshi001 requested review of D100616: [clang][NFC] Fix a potential assert failure.
Thu, Apr 15, 8:14 PM · Restricted Project

Wed, Apr 14

benshi001 added a comment to D97669: [clang][AVR] Add avr-libc/include to clang system include paths.

Is stdio.h used by anything?

No. stdio.h is not used. But if I do #include <avr/interrupt.h>, then -I /usr/lib/avr/include must be specified in the command line option. While avr-gcc does not reqiures that.

I would like to keep clang & avr-gcc in the behaviour.

Ok, do you plan to use it later? Then perhaps you should be adding it in the subsequent patches?

No. No future pathes are needed. The avr-libc includes standard libc (headers and libs) and avr specific headers and libs. This patch fixes all of these issues. Both standard libc and avr platform specific libs can be used without any explict command line option, just like avr-gcc does.

Ok, so your patch is adding the following file

clang/test/Driver/Inputs/basic_avr_tree/usr/lib/avr/include/stdio.h

But it doesn't seem to be used at present? If you don't need it anywhere it should not be added.

No. The stdio.h is still needed even it is not referred by any code in current patch. It works as a placeholder for the directory clang/test/Driver/Inputs/basic_avr_tree/usr/lib/avr/include/, and this directory is needed in the test case clang/test/Driver/avr-toolchain.c of current patch, and this directory can not exist without stdio.h.

Do you know why an empty directory is not sufficient?

Overall perhaps it makes more sense if someone with more experience on AVR reviews this change.

Wed, Apr 14, 5:59 PM · Restricted Project
benshi001 updated the diff for D97669: [clang][AVR] Add avr-libc/include to clang system include paths.
Wed, Apr 14, 5:57 PM · Restricted Project

Tue, Apr 13

benshi001 added a comment to D97669: [clang][AVR] Add avr-libc/include to clang system include paths.

Is stdio.h used by anything?

No. stdio.h is not used. But if I do #include <avr/interrupt.h>, then -I /usr/lib/avr/include must be specified in the command line option. While avr-gcc does not reqiures that.

I would like to keep clang & avr-gcc in the behaviour.

Ok, do you plan to use it later? Then perhaps you should be adding it in the subsequent patches?

No. No future pathes are needed. The avr-libc includes standard libc (headers and libs) and avr specific headers and libs. This patch fixes all of these issues. Both standard libc and avr platform specific libs can be used without any explict command line option, just like avr-gcc does.

Ok, so your patch is adding the following file

clang/test/Driver/Inputs/basic_avr_tree/usr/lib/avr/include/stdio.h

But it doesn't seem to be used at present? If you don't need it anywhere it should not be added.

Tue, Apr 13, 6:06 PM · Restricted Project

Fri, Apr 9

benshi001 committed rG4f173c0c42d0: [clang][AVR] Support variable decorator '__flash' (authored by benshi001).
[clang][AVR] Support variable decorator '__flash'
Fri, Apr 9, 8:24 PM
benshi001 closed D96853: [clang][AVR] Support variable decorator '__flash'.
Fri, Apr 9, 8:24 PM · Restricted Project

Thu, Apr 8

benshi001 added a comment to D97669: [clang][AVR] Add avr-libc/include to clang system include paths.

Is stdio.h used by anything?

No. stdio.h is not used. But if I do #include <avr/interrupt.h>, then -I /usr/lib/avr/include must be specified in the command line option. While avr-gcc does not reqiures that.

I would like to keep clang & avr-gcc in the behaviour.

Ok, do you plan to use it later? Then perhaps you should be adding it in the subsequent patches?

Thu, Apr 8, 7:48 PM · Restricted Project

Wed, Apr 7

benshi001 added inline comments to D97669: [clang][AVR] Add avr-libc/include to clang system include paths.
Wed, Apr 7, 3:44 AM · Restricted Project
benshi001 abandoned D100022: [clang][NFC] Fix method names not in accordance with coding style requirement.
Wed, Apr 7, 3:43 AM · Restricted Project

Tue, Apr 6

benshi001 added a comment to D100022: [clang][NFC] Fix method names not in accordance with coding style requirement.

It seems the class ToolChain and its sub classes also have other methods not in accordance with the coding style. But fixing all of them really needs big effort. Can we fix addClangSystemIncludeArgs first, and then let https://reviews.llvm.org/D97669 pass ?

Tue, Apr 6, 11:52 PM · Restricted Project
benshi001 added inline comments to D97669: [clang][AVR] Add avr-libc/include to clang system include paths.
Tue, Apr 6, 11:48 PM · Restricted Project
benshi001 requested review of D100022: [clang][NFC] Fix method names not in accordance with coding style requirement.
Tue, Apr 6, 11:46 PM · Restricted Project

Mon, Apr 5

benshi001 added a comment to D98335: [AVR] Refactor 8-bit & 16-bit shifts.

Some key points in my design,

Mon, Apr 5, 8:32 PM · Restricted Project
benshi001 updated the diff for D99237: [AVR][clang] Fix wrong calling convention in functions return struct type.
Mon, Apr 5, 7:01 PM · Restricted Project

Sun, Apr 4

benshi001 added a comment to D96853: [clang][AVR] Support variable decorator '__flash'.

Btw is any pointer conversion between address space 1 and the default address space allowed? I.e. is the following code valid:

__flash static const int var1[] = {111, 222, 333};
void foo(int*);
....
foo(var1);

or

__flash static const int var1[] = {111, 222, 333};
void foo(int*);
....
foo((int*)var1);

?

No. clang denied with error: passing 'const __attribute__((address_space(1))) int *' to parameter of type 'const int *' changes address space of pointer while avr-gcc accepted it.

It seems I need more efforts to make clang-avr fully compatible with avr-gcc.

Ok, it makes sense for clang to align with gcc in general but do you know whether or where this conversions are described? By default if not specified explicitly implicit conversions are always disallowed in ISO/IEC DTR 18037 and explicit casts are always allowed but can yeild undefined behavior if address spaces don't overlap.

Sun, Apr 4, 6:40 AM · Restricted Project

Thu, Apr 1

benshi001 added a comment to D97669: [clang][AVR] Add avr-libc/include to clang system include paths.

Is stdio.h used by anything?

Thu, Apr 1, 11:12 PM · Restricted Project
benshi001 added inline comments to D97669: [clang][AVR] Add avr-libc/include to clang system include paths.
Thu, Apr 1, 8:43 PM · Restricted Project
benshi001 updated the diff for D99237: [AVR][clang] Fix wrong calling convention in functions return struct type.
Thu, Apr 1, 8:10 PM · Restricted Project

Wed, Mar 31

benshi001 added inline comments to D96853: [clang][AVR] Support variable decorator '__flash'.
Wed, Mar 31, 7:26 AM · Restricted Project
benshi001 added a reviewer for D99237: [AVR][clang] Fix wrong calling convention in functions return struct type: Anastasia.
Wed, Mar 31, 7:23 AM · Restricted Project
benshi001 added a reviewer for D97669: [clang][AVR] Add avr-libc/include to clang system include paths: Anastasia.
Wed, Mar 31, 7:22 AM · Restricted Project

Tue, Mar 30

benshi001 updated the diff for D96853: [clang][AVR] Support variable decorator '__flash'.
Tue, Mar 30, 8:48 PM · Restricted Project
benshi001 added inline comments to D96853: [clang][AVR] Support variable decorator '__flash'.
Tue, Mar 30, 8:35 PM · Restricted Project
benshi001 added a comment to D96853: [clang][AVR] Support variable decorator '__flash'.

Btw is any pointer conversion between address space 1 and the default address space allowed? I.e. is the following code valid:

__flash static const int var1[] = {111, 222, 333};
void foo(int*);
....
foo(var1);

or

__flash static const int var1[] = {111, 222, 333};
void foo(int*);
....
foo((int*)var1);

?

Tue, Mar 30, 8:32 PM · Restricted Project
benshi001 added a comment to D96853: [clang][AVR] Support variable decorator '__flash'.
Tue, Mar 30, 8:29 PM · Restricted Project
benshi001 updated the diff for D96853: [clang][AVR] Support variable decorator '__flash'.
Tue, Mar 30, 8:11 PM · Restricted Project
benshi001 added inline comments to D96853: [clang][AVR] Support variable decorator '__flash'.
Tue, Mar 30, 6:42 PM · Restricted Project

Sun, Mar 28

benshi001 added a comment to D99467: [AVR] Fix a bug in prologue of ISR.

avr-gcc does

Sun, Mar 28, 8:02 AM · Restricted Project
benshi001 requested review of D99467: [AVR] Fix a bug in prologue of ISR.
Sun, Mar 28, 8:00 AM · Restricted Project

Sat, Mar 27

benshi001 added a reviewer for D96853: [clang][AVR] Support variable decorator '__flash': Anastasia.
Sat, Mar 27, 12:12 AM · Restricted Project
benshi001 updated the diff for D96853: [clang][AVR] Support variable decorator '__flash'.
Sat, Mar 27, 12:11 AM · Restricted Project

Fri, Mar 26

benshi001 added a comment to D96853: [clang][AVR] Support variable decorator '__flash'.

I am guessing this will only be supported by 1 target in clang? Then target address spaces make sense otherwise you can also extend the language address space enum. Are you also planning to add __flashN?
https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html

Fri, Mar 26, 7:11 PM · Restricted Project
benshi001 added a comment to D96394: [AVR] Improve inline assembly.

fixes https://bugs.llvm.org/show_bug.cgi?id=48480

Fri, Mar 26, 9:43 AM · Restricted Project
benshi001 added a comment to D96853: [clang][AVR] Support variable decorator '__flash'.

fixes https://bugs.llvm.org/show_bug.cgi?id=31568

Fri, Mar 26, 9:42 AM · Restricted Project
benshi001 added a comment to D99237: [AVR][clang] Fix wrong calling convention in functions return struct type.

fully fixes https://bugs.llvm.org/show_bug.cgi?id=39251
partially fixes https://bugs.llvm.org/show_bug.cgi?id=46140

Fri, Mar 26, 9:41 AM · Restricted Project

Wed, Mar 24

benshi001 added a comment to D99237: [AVR][clang] Fix wrong calling convention in functions return struct type.

This patch just fix the wrong return type in ABI. The wrong parameters passing with be fixed in another patch.

Wed, Mar 24, 6:50 PM · Restricted Project

Tue, Mar 23

benshi001 requested review of D99239: [AVR][test] Add a new test: functions with struct return type.
Tue, Mar 23, 11:47 PM · Restricted Project
benshi001 updated the diff for D99237: [AVR][clang] Fix wrong calling convention in functions return struct type.
Tue, Mar 23, 10:42 PM · Restricted Project
benshi001 requested review of D99237: [AVR][clang] Fix wrong calling convention in functions return struct type.
Tue, Mar 23, 9:24 PM · Restricted Project

Mar 10 2021

benshi001 added a comment to D98335: [AVR] Refactor 8-bit & 16-bit shifts.

As shown in test case https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/AVR/shift.ll,

Mar 10 2021, 6:29 AM · Restricted Project
benshi001 added a comment to D98335: [AVR] Refactor 8-bit & 16-bit shifts.

Other optimization such as ashr x, 6 and ashr x, 15 can be easily added in future patches along this way.

Mar 10 2021, 5:56 AM · Restricted Project
benshi001 updated the diff for D98335: [AVR] Refactor 8-bit & 16-bit shifts.
Mar 10 2021, 5:53 AM · Restricted Project
benshi001 abandoned D96506: [AVR] Optimize 16-bit shifts.
Mar 10 2021, 5:38 AM · Restricted Project
benshi001 added a comment to D96506: [AVR] Optimize 16-bit shifts.

I should have explained this a while ago, sorry for neglecting this.

See my comment D89047#2366709.
I think this optimization would be implemented better in SelectionDAG instead of using pseudo-instructions. That would also make it possible to optimize things like (short)x << 12.

Could you please explain more about be implemented better in SelectionDAG instead of using pseudo-instructions ? I can not figure out a way using SelectionDAG. Because I think SelectionDAG requires data flow dependency and looks like a tree structure. But The mov/clr pair seems can not be put into a tree structure.

Sorry I meant in the MachineIR phase. I think the ideal way to expand bit shift operations is as follows:

  1. Lower lsl/lshr/ashr operations in SelectionDAG to pseudo instructions that have a constant immediate operand. You will only need six pseudo instructions this way: for lsl/lshr/ashr and for both 8 bit and 16 bit versions. These pseudo instructions should have the usesCustomInserter flag set.
  2. Expand these instructions in AVRTargetLowering::EmitInstrWithCustomInserter. There are already a few existing expansions in there.

The big advantage is that you can do shifts before register allocation and I think it is also easier to structure the code. Also, this means you don't need as many instructions to expand in the pseudo instruction expansion pass.

Recently I have been thinking a lot about constant shifts on AVR and I've written a blog post here: https://aykevl.nl/2021/02/avr-bitshift
I think you will find it useful.

To be clear: I really appreciate your work on the AVR backend. There are many things that need to be improved, such as these bit shift operations. But I think there is a different and possibly better way to implement these expansions.

Mar 10 2021, 5:36 AM · Restricted Project
benshi001 added a comment to D98335: [AVR] Refactor 8-bit & 16-bit shifts.

As @aykevl suggested in https://aykevl.nl/2021/02/avr-bitshift,

Mar 10 2021, 5:27 AM · Restricted Project
benshi001 requested review of D98335: [AVR] Refactor 8-bit & 16-bit shifts.
Mar 10 2021, 5:16 AM · Restricted Project

Mar 5 2021

benshi001 added inline comments to D96394: [AVR] Improve inline assembly.
Mar 5 2021, 5:58 AM · Restricted Project
benshi001 updated the diff for D96394: [AVR] Improve inline assembly.
Mar 5 2021, 5:49 AM · Restricted Project

Mar 4 2021

benshi001 added a comment to D97127: [AVR] Improve 8/16 bit atomic operations.

Do we need a test case to show the right AVR assembly ? Or at least shows that the points #1 and #2 in your comment are fixed.

I think that would imply using hardcoded registers in the test. Is that what you mean?

No. I meant, you have shown a case void atomicadd(_Atomic char *val) and corresponding assembly, and I would like to see the change of the generated assembly by your patch, and wonder if the change can be added as a test case.

There are tests in llvm/test/CodeGen/AVR/atomics/load8.ll for example. However while the assembly has changed, patterns like [[RR:r[0-9]+]] are used so the test does not change. Therefore, I think the only way to show the bug is fixed is by hardcoding registers.
Or do you see another way?

Mar 4 2021, 6:27 AM · Restricted Project
benshi001 added a comment to D96394: [AVR] Improve inline assembly.

Sorry, English is not my first language, I expect I have explained everything clearly. ^_^

Mar 4 2021, 5:10 AM · Restricted Project
benshi001 added a comment to D96394: [AVR] Improve inline assembly.

Oh, I missed this comment.

Though i32/i64 types are not supported currently, the inline asm for i8/i16 of llvm-avr
get full comtability with avr-gcc by my patch.

I will try to fix i32/i64 failure in inline-asm in the future.

What should i32/i64 do? AVR only has registers up to 16 bits.

Mar 4 2021, 4:53 AM · Restricted Project
benshi001 added a comment to D96394: [AVR] Improve inline assembly.

I don't really understand what you're doing here. For example:

case 'd': // Upper registers r16..r31.
  if (VT == MVT::i8)
    return std::make_pair(0U, &AVR::LD8RegClass);
  else if (VT == MVT::i16)
    return std::make_pair(0U, &AVR::DLDREGSRegClass);
  break;

If I'm reading https://www.nongnu.org/avr-libc/user-manual/inline_asm.html correctly, this appears to imply an 8-bit register, but you're also implementing support for 16-bit registers. Why?

Mar 4 2021, 4:49 AM · Restricted Project
benshi001 added inline comments to D96394: [AVR] Improve inline assembly.
Mar 4 2021, 4:25 AM · Restricted Project

Mar 3 2021

benshi001 added a comment to D97127: [AVR] Improve 8/16 bit atomic operations.

Do we need a test case to show the right AVR assembly ? Or at least shows that the points #1 and #2 in your comment are fixed.

I think that would imply using hardcoded registers in the test. Is that what you mean?

Mar 3 2021, 6:42 PM · Restricted Project
benshi001 accepted D96969: [AVR] Only support sp, r0 and r1 in llvm.read_register.
Mar 3 2021, 6:29 PM · Restricted Project
benshi001 added a comment to D97669: [clang][AVR] Add avr-libc/include to clang system include paths.

Although the bug can be avoided via "-I /usr/lib/avr/include" in clang's command line option, I expect clang to have the save behaviour as avr-gcc.

Mar 3 2021, 6:23 PM · Restricted Project
benshi001 added a reviewer for D97669: [clang][AVR] Add avr-libc/include to clang system include paths: rjmccall.
Mar 3 2021, 6:19 PM · Restricted Project
benshi001 added a comment to D97172: [AVR] Fix lifeness issues in the AVR backend.

Re-upload (without changes) to try to get the buildbot working...

Mar 3 2021, 6:12 PM · Restricted Project

Mar 1 2021

benshi001 updated the diff for D96853: [clang][AVR] Support variable decorator '__flash'.
Mar 1 2021, 10:57 PM · Restricted Project
benshi001 added a comment to D97172: [AVR] Fix lifeness issues in the AVR backend.

We need to fix the build failure before commit this patch.

What do you mean? Which build failure should be fixed?

Mar 1 2021, 6:17 PM · Restricted Project
benshi001 added a comment to D97131: [AVR] Fix expansion of NEGW.

Why not commit it? I think this bug fix should be fixed ASAP.

I prefer doing multiple commits at once and it doesn't affect me other than during unrelated AVR backend development. Would you like to see it fixed right away?

Yes. I appreciate if you commit your patches. I will do my future work based on it (to avoid potential merge conflict between us)

Mar 1 2021, 6:11 PM · Restricted Project
benshi001 added a comment to D97131: [AVR] Fix expansion of NEGW.

Why not commit it? I think this bug fix should be fixed ASAP.

I prefer doing multiple commits at once and it doesn't affect me other than during unrelated AVR backend development. Would you like to see it fixed right away?

Mar 1 2021, 6:05 PM · Restricted Project
benshi001 added a comment to D97669: [clang][AVR] Add avr-libc/include to clang system include paths.

Looks reasonable to me. But again, I would like this to be reviewed also by someone familiar with the internals of Clang (I'm not).

Mar 1 2021, 5:47 PM · Restricted Project
benshi001 added a comment to D97669: [clang][AVR] Add avr-libc/include to clang system include paths.

The wrong stdio.h (/usr/include/stdio.h) is included with a simple a.c like

Mar 1 2021, 1:57 AM · Restricted Project
benshi001 requested review of D97669: [clang][AVR] Add avr-libc/include to clang system include paths.
Mar 1 2021, 1:54 AM · Restricted Project

Feb 28 2021

benshi001 accepted D97172: [AVR] Fix lifeness issues in the AVR backend.

We need to fix the build failure before commit this patch.

Feb 28 2021, 7:54 PM · Restricted Project
benshi001 added a comment to D97127: [AVR] Improve 8/16 bit atomic operations.

Do we need a test case to show the right AVR assembly ? Or at least shows that the points #1 and #2 in your comment are fixed.

Feb 28 2021, 7:20 PM · Restricted Project

Feb 24 2021

benshi001 added a comment to D97131: [AVR] Fix expansion of NEGW.

Why not commit it? I think this bug fix should be fixed ASAP.

Feb 24 2021, 6:19 PM · Restricted Project
benshi001 added a comment to D96506: [AVR] Optimize 16-bit shifts.

I should have explained this a while ago, sorry for neglecting this.

See my comment D89047#2366709.
I think this optimization would be implemented better in SelectionDAG instead of using pseudo-instructions. That would also make it possible to optimize things like (short)x << 12.

Could you please explain more about be implemented better in SelectionDAG instead of using pseudo-instructions ? I can not figure out a way using SelectionDAG. Because I think SelectionDAG requires data flow dependency and looks like a tree structure. But The mov/clr pair seems can not be put into a tree structure.

Sorry I meant in the MachineIR phase. I think the ideal way to expand bit shift operations is as follows:

  1. Lower lsl/lshr/ashr operations in SelectionDAG to pseudo instructions that have a constant immediate operand. You will only need six pseudo instructions this way: for lsl/lshr/ashr and for both 8 bit and 16 bit versions. These pseudo instructions should have the usesCustomInserter flag set.
  2. Expand these instructions in AVRTargetLowering::EmitInstrWithCustomInserter. There are already a few existing expansions in there.

The big advantage is that you can do shifts before register allocation and I think it is also easier to structure the code. Also, this means you don't need as many instructions to expand in the pseudo instruction expansion pass.

Recently I have been thinking a lot about constant shifts on AVR and I've written a blog post here: https://aykevl.nl/2021/02/avr-bitshift
I think you will find it useful.

To be clear: I really appreciate your work on the AVR backend. There are many things that need to be improved, such as these bit shift operations. But I think there is a different and possibly better way to implement these expansions.

Feb 24 2021, 6:18 PM · Restricted Project

Feb 22 2021

benshi001 added a comment to D96969: [AVR] Only support sp, r0 and r1 in llvm.read_register.

there is a lint warning.

Feb 22 2021, 7:28 PM · Restricted Project

Feb 21 2021

benshi001 added inline comments to D97159: [AVR] Fix def state of operands.
Feb 21 2021, 6:04 PM · Restricted Project
benshi001 accepted D97159: [AVR] Fix def state of operands.

Generally I am OK with this patch, except there is a lint warning.

Feb 21 2021, 6:03 PM · Restricted Project
benshi001 added a comment to D96677: [AVR] Expand large shifts early in IR.

I am not sure such a specific pass is needed. Why __ashlsi3 is not called in other backends? Is there a config flag/option to prevent calling __ashlsi3 ?

Because most instruction sets do support 32-bit shifts but AVR does not. For example, it appears that the MSP430 has the same problem: https://reviews.llvm.org/D78663#2215170.

I've investigated whether there are any other options to this but I couldn't come up with any. The builtin calls are created inside SelectionDAG which converts non-constant shifts to library calls. Therefore, this pass converts non-constant shifts to constant shifts in a loop to match avr-gcc so that the resulting code does not contain any 32-bit non-constant shifts.

Feb 21 2021, 5:01 PM · Restricted Project
benshi001 added a comment to D96677: [AVR] Expand large shifts early in IR.

I am not sure such a specific pass is needed. Why __ashlsi3 is not called in other backends? Is there a config flag/option to prevent calling __ashlsi3 ?

Feb 21 2021, 7:08 AM · Restricted Project
benshi001 added inline comments to D96957: [AVR] Fix rotate instructions.
Feb 21 2021, 6:56 AM · Restricted Project
benshi001 accepted D96492: [AVR] Add register aliases XL, YH, etc.
Feb 21 2021, 6:05 AM · Restricted Project
benshi001 added inline comments to D96492: [AVR] Add register aliases XL, YH, etc.
Feb 21 2021, 6:03 AM · Restricted Project
benshi001 accepted D97131: [AVR] Fix expansion of NEGW.
Feb 21 2021, 5:49 AM · Restricted Project
benshi001 updated the diff for D96853: [clang][AVR] Support variable decorator '__flash'.
Feb 21 2021, 5:45 AM · Restricted Project
benshi001 updated the diff for D96853: [clang][AVR] Support variable decorator '__flash'.
Feb 21 2021, 5:39 AM · Restricted Project
benshi001 added a reviewer for D96677: [AVR] Expand large shifts early in IR: benshi001.
Feb 21 2021, 5:37 AM · Restricted Project

Feb 20 2021

benshi001 added inline comments to D97131: [AVR] Fix expansion of NEGW.
Feb 20 2021, 9:39 PM · Restricted Project
benshi001 added a comment to D96853: [clang][AVR] Support variable decorator '__flash'.

I am not very familiar with Clang so I can't say much about it. Although I wonder whether a macro is the right way to implement this? Is there something similar in other targets? (GPUs tend to have lots of address spaces, you could take a look there).

Feb 20 2021, 5:50 PM · Restricted Project

Feb 18 2021

benshi001 added a comment to D96957: [AVR] Fix rotate instructions.

Also, there are lint errors, I think this patch is OK if all lint errors can be fixed.

Feb 18 2021, 7:37 PM · Restricted Project

Feb 17 2021

benshi001 added a comment to D96853: [clang][AVR] Support variable decorator '__flash'.

This patch immitates avr-gcc behavior on __flash

Feb 17 2021, 3:16 AM · Restricted Project
benshi001 requested review of D96853: [clang][AVR] Support variable decorator '__flash'.
Feb 17 2021, 3:13 AM · Restricted Project

Feb 15 2021

benshi001 added inline comments to D96492: [AVR] Add register aliases XL, YH, etc.
Feb 15 2021, 9:02 PM · Restricted Project
benshi001 added inline comments to D96677: [AVR] Expand large shifts early in IR.
Feb 15 2021, 8:59 PM · Restricted Project

Feb 13 2021

benshi001 added a comment to D96590: [AVR] Fix a bug in 16-bit shifts.

@benshi001 can you commit it or should I do it for you?

Feb 13 2021, 7:56 PM · Restricted Project
benshi001 committed rGefb1cb752bf1: [AVR] Fix a bug in 16-bit shifts (authored by benshi001).
[AVR] Fix a bug in 16-bit shifts
Feb 13 2021, 7:55 PM
benshi001 closed D96590: [AVR] Fix a bug in 16-bit shifts.
Feb 13 2021, 7:55 PM · Restricted Project

Feb 12 2021

benshi001 added a comment to D90092: [AVR] Optimize 16-bit int shift.

Thanks for reporting. I have submited a patch to fix that bug.
https://reviews.llvm.org/D96590

Feb 12 2021, 3:34 AM · Restricted Project
benshi001 requested review of D96590: [AVR] Fix a bug in 16-bit shifts.
Feb 12 2021, 3:33 AM · Restricted Project