Replace MACROS with hashmap

[icgmilk]

This PR introduced 'MACROS_MAP' to replace the original 'MACROS' structure, and refactored related logic with hashmap utilities.

To make this change improves memory flexibility and future extensibility, I set MAX_ALIASES to 128.
The original value (1024) is excessive, as uftrace analysis shows that the number of aliases rarely exceeds 64 in practice(measured via uftrace record ./out/shecc ./src/main.c), and the total number of #defines in shecc is typically below 70.
In shecc's hashmap implementation, a rehash is triggered when the number of entries exceeds 75% of the capacity.
With this load factor of 0.75, a capacity of 128 supports up to 96 entries before rehashing, which comfortably covers observed usage while providing sufficient headroom.
In contrast, a capacity of 64 only allows 48 entries, increasing the likelihood of rehashing.
uftrace confirms this: setting MAX_ALIASES to 64 triggered one more hashmap_rehash compared to 128.
Therefore, I chose 128 over 64 to avoid unnecessary rehashing while still keeping memory usage significantly lower than the original default.

Performance analysis for out/shecc src/main.c

set `MAX_ALIASES` to 128

51.233 us 32.695 us 4 hashmap_rehash

set `MAX_ALIASES` to 64

56.218 us 35.418 us 5 hashmap_rehash

Summary by Bito

This pull request enhances the code by replacing the static 'MACROS' structure with a dynamic hashmap, 'MACROS_MAP', improving memory usage and lookup performance from O(n) to O(1). The maximum number of aliases has been set to 128 to optimize performance and reduce rehashing.

[jserv]

Address the benefits of the proposed changes in commit message.

[fennecJ]

The idea of using a hashmap to improve macro lookup is good, but I wonder if it actually makes the program faster.

The original implementation:

MACROS = malloc(MAX_ALIASES * sizeof(macro_t)); // MAX_ALIASES = 1024 by default

• Preallocates a MACROS pool with a single malloc, while the new implementation calls malloc once for each inserted macro.
• The MACROS pool is linearly allocated in memory, which is cache-friendly. In contrast, the hashmap uses linked lists, with pointers pointing to scattered memory locations across different cache lines — which is not cache-friendly.

Based on these two points, I don't think the new implementation improves compiler performance.
Perhaps preallocating a MACROS pool and using a hash-based index could be a better compromise.
Alternatively, have you benchmarked the new implementation to confirm it's actually faster?

[icgmilk]

The idea of using a hashmap to improve macro lookup is good, but I wonder if it actually makes the program faster.

The original implementation:

MACROS = malloc(MAX_ALIASES * sizeof(macro_t)); // MAX_ALIASES = 1024 by default

• Preallocates a MACROS pool with a single malloc, while the new implementation calls malloc once for each inserted macro.
• The MACROS pool is linearly allocated in memory, which is cache-friendly. In contrast, the hashmap uses linked lists, with pointers pointing to scattered memory locations across different cache lines — which is not cache-friendly.

Based on these two points, I don't think the new implementation improves compiler performance. Perhaps preallocating a MACROS pool and using a hash-based index could be a better compromise. Alternatively, have you benchmarked the new implementation to confirm it's actually faster?

Thanks for pointing that out, you're right that this implementation doesn't improve compiler performance.
That said, I believe it's still beneficial in terms of memory flexibility and future extensibility.
I'll update the description accordingly. Thanks for the feedback!

[jserv]

this implementation doesn't improve compiler performance. That said, I believe it's still beneficial in terms of memory flexibility and future extensibility. I'll update the description accordingly. Thanks for the feedback!

Could you show the real benefits for memory flexibility with specific numbers?

[ChAoSUnItY]

Overall logic looks good to me, but please provide a analysis on adjustment of MAX_ALIASES.

[ChAoSUnItY]

Please provide a analysis on MAX_ALIASES's configuration, that is, which power of 2 to represent it would be more efficient in this case? As you stated, this patch provides memory flexibility for macro_t structure allocation, however, it's obvious that 1024 is overkill for this purpose.

[icgmilk]

I used uftrace to analyze the impact of different MAX_ALIASES configurations and found that setting it to 128 resulted in the fewest hashmap_rehash calls during execution while maintaining the smallest stable size.
The detailed analysis and results are documented in the commit message for reference.

[jserv]

Thank @icgmilk for contributing!