[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-08-27 Thread Anatoly Trosinenko via Phabricator via cfe-commits
atrosinenko added a comment. Pinging @echristo in case there is some trivial way to allocate a calling convention ID (but probably there is not, unless GCC allocated one already). As I understand, without this ID the debugger may show some misleading output for a limited number of LibCalls. On

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-08-27 Thread Anatoly Trosinenko via Phabricator via cfe-commits
atrosinenko updated this revision to Diff 288305. atrosinenko added a comment. - Rebase onto current master branch - Add a dummy `switch` case with `FIXME`, as suggested by @aaron.ballman - Applied a couple of style fixes proposed by linter Repository: rG LLVM Github Monorepo CHANGES SINCE LA

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-08-14 Thread Anatoly Trosinenko via Phabricator via cfe-commits
atrosinenko added a comment. In D84602#2206512 , @aaron.ballman wrote: > I still think this case needs some work to keep the bots happy. I would > probably go with: > > case CC_MSP430Builtin: > > // FIXME: Currently unsupported > break; > > But perha

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-08-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a reviewer: echristo. aaron.ballman added a subscriber: echristo. aaron.ballman added a comment. Adding @echristo for the debugging info question. In D84602#2200274 , @atrosinenko wrote: > I suspect there might be some terminology clas

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-08-06 Thread Anatoly Trosinenko via Phabricator via cfe-commits
atrosinenko added a comment. I suspect there might be some terminology clash, so clarifying a bit just in case. It was probably better to refer to these functions as //LibCalls// - functions from the compiler support library (such as `libgcc`) such as `__adddf3`. While there are `__popcount[sd

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-07-28 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment. In D84602#2178328 , @atrosinenko wrote: > In D84602#2176592 , @aaron.ballman > wrote: > >> To be clear, I also don't have a problem with it, but if users aren't >> supposed to be wri

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-07-28 Thread Anatoly Trosinenko via Phabricator via cfe-commits
atrosinenko updated this revision to Diff 281198. atrosinenko added a comment. Fix some review comments. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D84602/new/ https://reviews.llvm.org/D84602 Files: clang/include/clang/Basic/Attr.td clang/in

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-07-28 Thread Anatoly Trosinenko via Phabricator via cfe-commits
atrosinenko added a comment. In D84602#2176584 , @rjmccall wrote: > Is there only one special calling convention, or is there any chance that > different builtin functions would use different conventions? It depends on how to define "builtin calling conv

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-07-28 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments. Comment at: clang/include/clang/Basic/Attr.td:1465 + let Spellings = [Clang<"msp430_builtin">]; + let Documentation = [Undocumented]; +} atrosinenko wrote: > aaron.ballman wrote: > > No new, undocumented attributes, please.

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-07-28 Thread Anatoly Trosinenko via Phabricator via cfe-commits
atrosinenko added inline comments. Comment at: clang/include/clang/Basic/Attr.td:1465 + let Spellings = [Clang<"msp430_builtin">]; + let Documentation = [Undocumented]; +} aaron.ballman wrote: > No new, undocumented attributes, please. Or is this attribute not

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-07-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment. In D84602#2176584 , @rjmccall wrote: > I don't have a problem with introducing a new convention even if it's only > used for "builtin" functions. To be clear, I also don't have a problem with it, but if users aren't suppos

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-07-27 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment. Is there only one special calling convention, or is there any chance that different builtin functions would use different conventions? I don't have a problem with introducing a new convention even if it's only used for "builtin" functions. Repository: rG LLVM Githu

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-07-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments. Comment at: clang/include/clang/Basic/Attr.td:1465 + let Spellings = [Clang<"msp430_builtin">]; + let Documentation = [Undocumented]; +} No new, undocumented attributes, please. Or is this attribute not expected to be used

[PATCH] D84602: [MSP430] Expose msp430_builtin calling convention to C code

2020-07-26 Thread Anatoly Trosinenko via Phabricator via cfe-commits
atrosinenko created this revision. atrosinenko added reviewers: asl, aaron.ballman, rjmccall. Herald added subscribers: llvm-commits, hiraditya. Herald added projects: clang, LLVM. According to MSP430 EABI document , Section 6.3, some of compiler